From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 11:13:31 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM4×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:14:01 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM4Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 13 15:21:26 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:21:27 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 13 15:21:27 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 13 15:21:27 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 15:21:27 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM4ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 16:00:57 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM4ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 13 20:01:58 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM4ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 08:02:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 14 08:02:33 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 08:02:33 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 14 08:02:33 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 14 08:02:33 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 08:02:33 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM4ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 12:00:56 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM4ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 16:00:53 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM4ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 14 20:00:53 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 15 08:02:20 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 08:02:20 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM4÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 08:02:21 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 15 12:01:00 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 12:01:00 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 15 12:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 15 12:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 12:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5Ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 12:01:01 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 16:00:53 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 15 20:00:52 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 08:02:45 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 16 12:00:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 12:00:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 16 12:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 16 12:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 12:00:57 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 16 16:00:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 16:00:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 16 16:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 16 16:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 16:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 16:00:57 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 16 20:00:54 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 08:02:48 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 17 12:01:14 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 17 12:01:15 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 12:01:15 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM5÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 16:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 17 16:01:01 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 16:01:01 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 17 16:01:01 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 17 16:01:01 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 16:01:01 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6Ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 17 20:01:00 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 08:04:34 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Jan 18 12:01:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 12:01:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 18 12:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Jan 18 12:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 12:01:16 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Jan 18 16:01:47 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 16:01:47 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 18 16:01:47 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Jan 18 16:01:47 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 16:01:48 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 18 20:01:07 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Jan 19 08:04:54 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 08:04:55 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 12:01:12 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Jan 19 16:03:40 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 16:03:40 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 19 16:03:40 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Jan 19 16:03:40 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 16:03:40 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 16:03:40 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 16:03:40 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 16:03:40 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 16:03:41 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 16:03:41 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 19 16:03:41 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 16:03:41 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Jan 19 16:03:41 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 16:03:41 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Jan 19 16:03:41 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Jan 19 16:03:41 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 16:03:41 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 20:00:57 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Jan 19 20:00:58 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Jan 19 20:00:58 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 19 20:00:58 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM6÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 08:07:55 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 20 12:02:28 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7Ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 20 12:02:29 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 12:02:30 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 16:01:02 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 20 20:00:59 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 21 08:04:13 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 08:04:13 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 08:04:14 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 21 12:01:12 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 12:01:12 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 21 12:01:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 21 12:01:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 12:01:13 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 16:01:01 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 21 20:00:58 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 20:00:58 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 21 20:00:58 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 21 20:00:58 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 21 20:00:59 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 22 08:03:03 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 08:03:04 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 12:01:02 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM7÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 22 16:01:38 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 16:01:39 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 22 16:01:39 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 22 16:01:39 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 16:01:39 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8Ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 22 20:01:32 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 20:01:33 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 22 20:01:34 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 22 20:01:34 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 22 20:01:34 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 08:03:00 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 23 12:01:07 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 12:01:07 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 23 12:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 23 12:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 12:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 12:01:08 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 23 16:02:13 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 16:02:13 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 23 16:02:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 23 16:02:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 16:02:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 16:02:13 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 16:02:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 16:02:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 16:02:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 16:02:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 23 16:02:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 16:02:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 23 16:02:14 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 16:02:14 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 23 16:02:14 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 23 16:02:14 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 16:02:14 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 23 20:01:03 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 08:03:33 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 24 12:03:41 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 12:03:42 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 24 12:03:42 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 24 12:03:42 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 12:03:42 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 12:03:43 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 12:03:43 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 12:03:43 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 12:03:43 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 12:03:43 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 24 12:03:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 12:03:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 24 12:03:43 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 12:03:44 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 24 12:03:44 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 24 12:03:44 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 12:03:44 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 24 16:01:42 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 16:01:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 24 16:01:43 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 16:01:43 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 24 16:01:43 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 24 16:01:43 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 16:01:43 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 24 20:02:09 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Jan 25 08:02:23 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 08:02:23 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 25 08:02:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Jan 25 08:02:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 08:02:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM8÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 08:02:24 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9Ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 12:01:19 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 16:01:15 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Jan 25 20:01:07 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 20:01:08 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Jan 25 20:01:08 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Jan 25 20:01:08 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Jan 25 20:01:08 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 08:06:49 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 12:01:21 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Jan 26 16:01:04 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 16:01:04 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 26 16:01:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Jan 26 16:01:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 16:01:05 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Jan 26 20:00:56 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 27 08:07:44 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 08:07:44 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 27 08:07:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 27 08:07:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 08:07:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 08:07:44 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 08:07:45 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 12:02:26 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM9÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 16:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 27 16:01:20 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 16:01:20 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 27 16:01:20 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 27 16:01:20 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 16:01:20 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:Ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Jan 27 20:01:10 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 28 08:06:24 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 08:06:25 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 12:02:07 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 28 16:01:06 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 16:01:06 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 28 16:01:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 28 16:01:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 16:01:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 16:01:06 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 16:01:06 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 16:01:06 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 16:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 16:01:07 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 28 16:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 16:01:07 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 28 16:01:07 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 16:01:07 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 28 16:01:07 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 28 16:01:07 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 16:01:07 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Jan 28 20:01:05 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 20:01:05 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Jan 28 20:01:06 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 08:07:54 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 29 08:07:55 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 08:07:55 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 29 08:07:55 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 29 08:07:55 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 08:07:55 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 12:01:17 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 16:01:05 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 29 16:01:06 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 29 16:01:06 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 16:01:06 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Jan 29 20:01:08 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 30 08:10:32 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 08:10:34 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 30 08:10:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 30 08:10:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 08:10:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM:÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 08:10:38 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 08:10:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 08:10:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 08:10:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 08:10:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 30 08:10:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 08:10:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 30 08:10:39 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 08:10:39 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 30 08:10:39 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 30 08:10:39 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 08:10:39 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 30 12:04:21 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 12:04:21 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 30 12:04:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 30 12:04:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 12:04:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;Ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 12:04:21 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 12:04:22 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 30 16:04:40 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 16:04:40 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 30 16:04:40 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 30 16:04:40 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 16:04:41 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Jan 30 20:02:34 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 20:02:35 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 30 20:02:35 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Jan 30 20:02:35 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 20:02:35 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 20:02:35 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 20:02:35 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Jan 30 20:02:36 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 31 08:08:37 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 08:08:37 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 31 08:08:37 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 31 08:08:37 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 08:08:37 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 08:08:37 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 08:08:37 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 08:08:38 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 31 12:04:49 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 12:04:50 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 16:02:43 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Jan 31 20:01:22 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 1 08:10:54 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 08:10:55 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 1 12:03:08 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 12:03:08 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 1 12:03:08 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 1 12:03:08 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 12:03:09 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM;÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 1 16:01:20 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 16:01:21 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 1 16:01:21 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 1 16:01:21 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 16:01:21 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<Ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 1 20:01:15 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 1 20:01:16 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 1 20:01:16 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Feb 2 08:14:50 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 08:14:50 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 2 08:14:50 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Feb 2 08:14:50 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 08:14:51 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 08:14:51 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 08:14:52 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Feb 2 12:03:16 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 12:03:16 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 2 12:03:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Feb 2 12:03:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 12:03:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 12:03:16 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 12:03:16 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 12:03:16 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 12:03:16 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 12:03:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 2 12:03:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 12:03:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Feb 2 12:03:17 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 12:03:17 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Feb 2 12:03:17 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Feb 2 12:03:17 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 12:03:17 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Feb 2 16:01:24 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 16:01:24 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 2 16:01:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Feb 2 16:01:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 16:01:25 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 2 20:01:18 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Feb 3 08:14:04 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 08:14:05 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 3 08:14:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Feb 3 08:14:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 08:14:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 08:14:05 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 08:14:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 08:14:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 08:14:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 08:14:06 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 3 08:14:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 08:14:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Feb 3 08:14:06 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 08:14:06 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Feb 3 08:14:06 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Feb 3 08:14:06 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 08:14:06 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 12:03:11 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 16:01:18 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Feb 3 20:01:22 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 20:01:22 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 3 20:01:23 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Feb 4 08:09:29 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 08:09:29 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM<÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 08:09:30 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=Ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 12:03:13 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 16:01:28 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=Û8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 4 20:01:20 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Feb 5 08:08:23 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 08:08:23 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 5 08:08:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Feb 5 08:08:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 08:08:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=ß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 08:08:23 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 08:08:24 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Feb 5 12:03:10 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 12:03:10 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 5 12:03:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Feb 5 12:03:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 12:03:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=ã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 12:03:10 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 12:03:10 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 12:03:11 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=ç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 16:01:24 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Feb 5 20:01:16 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 20:01:16 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 5 20:01:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Feb 5 20:01:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 20:01:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=ë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 20:01:16 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 5 20:01:17 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=ï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 08:17:09 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 6 08:17:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 08:17:10 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Feb 6 08:17:10 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 08:17:10 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Feb 6 08:17:10 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Feb 6 08:17:10 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 08:17:10 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=ó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 12:03:17 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Feb 6 12:03:18 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Feb 6 12:03:18 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 12:03:18 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëM=÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 16:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 6 16:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 16:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Feb 6 16:01:22 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 16:01:22 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Feb 6 16:01:22 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Feb 6 16:01:22 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 16:01:22 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMtÓ8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 6 20:01:19 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Feb 7 08:27:24 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 08:27:25 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 7 08:27:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Feb 7 08:27:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 08:27:26 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMt×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 08:27:26 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 08:27:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 08:27:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 08:27:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 08:27:26 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 7 08:27:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 08:27:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Feb 7 08:27:27 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 08:27:27 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Feb 7 08:27:28 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Feb 7 08:27:28 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 08:27:28 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Feb 7 12:03:49 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 12:03:49 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 7 12:03:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Feb 7 12:03:49 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMtÛ8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 12:03:50 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Feb 7 16:01:28 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 16:01:28 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 7 16:01:28 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Feb 7 16:01:28 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 16:01:28 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMtß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 16:01:28 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 16:01:28 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 16:01:28 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 16:01:28 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 16:01:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 7 16:01:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 16:01:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Feb 7 16:01:29 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 16:01:29 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Feb 7 16:01:29 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Feb 7 16:01:29 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 16:01:29 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Feb 7 20:01:21 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMtã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 7 20:01:22 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 8 08:26:30 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 08:26:30 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 8 08:26:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 8 08:26:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 08:26:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMtç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 08:26:31 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 08:26:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 08:26:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 08:26:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 08:26:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 8 08:26:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 08:26:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 8 08:26:33 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 08:26:34 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 8 08:26:34 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 8 08:26:34 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 08:26:34 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMtë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 12:04:03 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 8 12:04:04 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 8 12:04:04 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 12:04:04 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMtï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 16:01:33 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMtó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 8 20:01:21 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMt÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 08:10:27 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMuÓ8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 12:03:47 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMu×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 16:01:34 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Feb 9 20:01:29 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMuÛ8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 9 20:01:30 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Feb 10 08:25:54 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 08:25:59 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 10 08:25:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Feb 10 08:25:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 08:26:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMuß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 08:26:04 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 08:26:04 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 08:26:04 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 08:26:04 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 08:26:04 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 10 08:26:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 08:26:04 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Feb 10 08:26:04 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 08:26:06 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Feb 10 08:26:07 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Feb 10 08:26:07 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 08:26:07 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Feb 10 12:04:13 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 12:04:13 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 10 12:04:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Feb 10 12:04:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 12:04:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMuã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 12:04:13 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 12:04:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 12:04:13 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 12:04:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 12:04:14 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 10 12:04:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 12:04:14 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Feb 10 12:04:14 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 12:04:14 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Feb 10 12:04:14 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Feb 10 12:04:14 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 12:04:14 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Feb 10 16:01:25 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 16:01:25 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 10 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Feb 10 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMuç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 16:01:27 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMuë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Feb 10 20:01:25 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Feb 11 08:14:04 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 08:14:04 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 11 08:14:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Feb 11 08:14:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 08:14:05 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMuï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 08:14:05 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 08:14:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 08:14:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 08:14:05 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 08:14:06 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 11 08:14:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 08:14:06 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Feb 11 08:14:06 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 08:14:06 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Feb 11 08:14:07 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Feb 11 08:14:07 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 08:14:07 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMuó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 12:03:12 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMu÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 16:01:22 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sat Feb 11 20:01:11 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 20:01:11 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 11 20:01:11 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sat Feb 11 20:01:11 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 20:01:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMvÓ8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 20:01:12 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 20:01:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 20:01:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 20:01:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sat Feb 11 20:01:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sat Feb 11 20:01:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 20:01:13 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sat Feb 11 20:01:13 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 20:01:13 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sat Feb 11 20:01:13 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sat Feb 11 20:01:13 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat Feb 11 20:01:13 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMv×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 08:10:44 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 12 08:10:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 08:10:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Feb 12 08:10:45 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 08:10:45 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Feb 12 08:10:45 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Feb 12 08:10:45 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 08:10:45 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Feb 12 12:03:16 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMvÛ8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 12:03:18 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMvß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 16:01:25 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Feb 12 16:01:26 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 16:01:26 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Feb 12 16:01:26 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Feb 12 16:01:27 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 16:01:27 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMvã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Sun Feb 12 20:01:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 20:01:16 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Sun Feb 12 20:01:16 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 20:01:16 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Sun Feb 12 20:01:19 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Sun Feb 12 20:01:19 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun Feb 12 20:01:19 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Feb 13 08:19:31 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 08:19:32 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 13 08:19:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Feb 13 08:19:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMvç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Feb 13 08:19:33 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 08:19:34 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Feb 13 12:03:39 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 12:03:39 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 13 12:03:39 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Feb 13 12:03:39 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 12:03:39 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMvë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 12:03:39 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 12:03:40 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Feb 13 16:01:44 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 16:01:44 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 13 16:01:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Feb 13 16:01:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMvï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 16:01:45 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Mon Feb 13 20:01:23 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 20:01:23 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 13 20:01:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Mon Feb 13 20:01:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 20:01:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMvó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 20:01:23 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 20:01:23 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 20:01:23 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 20:01:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Mon Feb 13 20:01:24 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Mon Feb 13 20:01:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 20:01:24 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Mon Feb 13 20:01:24 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 20:01:24 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Mon Feb 13 20:01:24 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Mon Feb 13 20:01:24 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon Feb 13 20:01:24 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Feb 14 08:21:43 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 08:21:43 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 14 08:21:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Feb 14 08:21:43 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 08:21:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMv÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 08:21:44 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 08:21:44 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 08:21:44 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 08:21:44 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 08:21:44 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 14 08:21:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 08:21:44 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Feb 14 08:21:45 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 08:21:45 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Feb 14 08:21:45 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Feb 14 08:21:45 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 08:21:45 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMwÓ8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 12:03:56 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Feb 14 12:03:57 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 12:03:57 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Feb 14 12:03:57 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Feb 14 12:03:57 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 12:03:57 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Feb 14 16:01:57 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 16:01:57 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 14 16:01:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Feb 14 16:01:57 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 16:01:58 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMw×8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 16:01:59 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMwÛ8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue Feb 14 20:01:29 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 15 08:33:17 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 08:33:17 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 08:33:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 15 08:33:17 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 08:33:18 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMwß8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 08:33:18 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 08:33:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 08:33:18 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 08:33:19 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 08:33:22 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 08:33:22 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 08:33:23 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 15 08:33:23 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 08:33:23 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 15 08:33:23 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 15 08:33:23 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 08:33:23 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMwã8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 15 12:06:12 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 15 12:06:13 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 12:06:13 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMwç8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 16:01:51 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 15 16:01:52 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 15 16:01:52 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 16:01:52 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 15 19:28:29 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 19:28:29 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMwë8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 19:28:31 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Wed Feb 15 20:15:27 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 20:15:27 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 20:15:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Wed Feb 15 20:15:27 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 20:15:28 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMwï8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 20:15:29 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 20:15:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 20:15:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 20:15:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Wed Feb 15 20:15:29 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Wed Feb 15 20:15:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 20:15:30 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Wed Feb 15 20:15:30 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 20:15:30 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Wed Feb 15 20:15:30 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Wed Feb 15 20:15:30 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed Feb 15 20:15:30 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Thu Feb 16 08:50:26 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 16 08:50:31 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 16 08:50:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Thu Feb 16 08:50:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 16 08:50:31 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMwó8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 16 08:50:31 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 16 08:50:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 16 08:50:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 16 08:50:31 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Thu Feb 16 08:50:32 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Thu Feb 16 08:50:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 16 08:50:32 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Thu Feb 16 08:50:32 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 16 08:50:32 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Thu Feb 16 08:50:32 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Thu Feb 16 08:50:32 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu Feb 16 08:50:32 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From hamish.lawson at gmail.com Fri Aug 12 12:43:15 2005
From: hamish.lawson at gmail.com (Hamish Lawson)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120335b6c7fb8@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
Message-ID: <9acacaa50508120343531c847@mail.gmail.com>
The following program gives a segmentation fault.
====
from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
====
It appears to get upset at the URL being outside the quotes.
I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
mx-experimental) with Python 2.4 on Solaris 9 Sparc.
Hamish Lawson
From mal at egenix.com Fri Aug 12 15:53:20 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Segmentation fault with mx.Tidy
In-Reply-To: <9acacaa50508120343531c847@mail.gmail.com>
References: <9acacaa50508120335b6c7fb8@mail.gmail.com>
<9acacaa50508120343531c847@mail.gmail.com>
Message-ID: <42FC9BC0.5020908@egenix.com>
Hamish Lawson wrote:
> The following program gives a segmentation fault.
>
> ====
> from mx.Tidy import tidy
> text = """Go here"""
> nerrors, nwarnings, tidied_text, errors = tidy(text)
> ====
>
> It appears to get upset at the URL being outside the quotes.
>
> I'm using version 0.3.0 of mx.Tidy (from version 0.9.0 of
> mx-experimental) with Python 2.4 on Solaris 9 Sparc.
It appears to be fixed in our repository:
>>> from mx.Tidy import tidy
text = """Go here"""
nerrors, nwarnings, tidied_text, errors = tidy(text)
>>> nerrors
0
>>> nwarnings
2
>>> tidied_text
'\n\n\n\n\n\nGo here\n\n\n\n'
>>> errors
'line 1 column 1 - Warning: inserting missing \'title\' element\nline 1 column 5 - Warning:
unknown attribute value "(null)"\n'
I guess it's time for another release :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 12 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From danny at asterisk.co.nz Tue Aug 16 17:09:23 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <430166F3.7050404@asterisk.co.nz>
Hi there!
After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
don't work anymore!
System before migration:
- Debian Sarge
- Python 2.3.3
- Zope 2.7.0
- iODBC
- mxODBC, mxODBCZopeDA 1.0.8 (licensed)
(btw, the connection is to an Informix database)
Migration:
- Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
- Built Zope 2.8.1 from source using Python 2.3.5
- copied directory "mx" over to new Python and "mxODBCZopeDA" over to
new Zope
- Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
the previous step showed an error message), so I installed
mxODBC(ZopeDA) 1.0.9, as it says on the website.
- Everything else unchanged.
- Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
everything seemed to be fine. No errors in event.log.
Issues:
Let me mention that everything else works fine, it's just the mxODBC
connections that are broken.
After experiencing below problems, I deleted all mxODBC database
connection objects and restarted Zope.
It has no problems at all without these objects! But as soon as I add one...
I can reproduce the following, as often as I like, from scratch:
- Go to ZMI, add "eGenix mxODBC Database Connection" object to a folder:
Set id "Test", set title, set (proper) connection string, tick "open",
leave rest as default, click "Create Connection"
- Object is created without problems. Connection is open, "Test" tab
works fine.
- Restart Zope (!)
- Go back to ZMI folder where connection object was added
- First indication: The title of the connection object now reads "eGenix
mxODBC Database Connection" instead of the given title.
- Click on the connection object in the ZMI brings:
------------------------------
Traceback (innermost last):
Module ZPublisher.Publish, line 113, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 40, in call_object
Module Shared.DC.Scripts.Bindings, line 311, in __call__
Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec
Module App.special_dtml, line 175, in _exec
Module DocumentTemplate.DT_Util, line 196, in eval
- __traceback_info__: options
Module , line 0, in ?
AttributeError: 'NoneType' object has no attribute 'get'
------------------------------
- I manually entered "manage_UndoForm" and can confirm that the above
error comes on both "Status" and "Properties" tab. Seems like "options"
isn't set.
- When I create a script which takes the connection object and prints
its "title_or_id()", I get "eGenix mxODBC Database Connection ( not connected)". If I make it print
str(connection.options), I get "None" --- just like the management
screens seem to think.
- The connection is not open, ZSQL Methods don't find it, and if I now
add a _new_ connection object to the same folder, it has the same
problem straight away!
- If I add a new _folder_ and then a new connection inside that folder,
I can access it. After a Zope restart, those connections are broken, too.
- Please don't forget: All other objects are fine. If I delete the
connections and restart Zope, everything (else) is fine.
- The first time I started Zope after the upgrade I got
------------------------------
2005-08-16T13:33:02 ERROR ZODB.Connection Couldn't load state for None
Traceback (most recent call last):
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 704, in setstate
self._setstate(obj)
File "/opt/Zope-2.8.1/lib/python/ZODB/Connection.py", line 742, in
_setstate
p, serial = self._storage.load(obj._p_oid, self._version)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
548, in load
pos = self._lookup_pos(oid)
File "/opt/Zope-2.8.1/lib/python/ZODB/FileStorage/FileStorage.py", line
516, in _lookup_pos
raise TypeError("invalid oid %r" % (oid,))
TypeError: invalid oid None
------------------------------
when trying to access the (BTree)folder which contained the connection
object. This problem is gone since I deleted the connection objects.
Altogether I have two connection objects in two different locations
using the same connection string.
Zope restarts are needed sometimes.
For some reason still unknown to me, Zope starts hanging and I have to
manually kill it (Note: this doesn't happen and is not necessary when
the mxODBC connection objects are gone).
But restarting breaks my objects, so I'm back to being screwed.
Has anyone have similar experiences?
Where can I look for a solution?
It seems to me like something that needs to be persistently stored in
the ZODB isn't...
Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
This is for a client, and they need to use the database connection every
day (including today :-().
Please help.
Cheers,
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
Regarding the general release strategy it looks like we are going to have to
drop our support for all possible versions of Zope due to the pace of
releases of Zope - a new release every six months according to release
manager Andreas Jung - and the significant changes in architecture. We're
proposing to release a fixed version of the DA for Zope 2.6, 2.7 and 2.8 with
other versions available only on request and want to know what your reaction
is. Do we have heavy uses of mxODBCZopeDA on older versions of Zope who are
not able to migrate to one of these versions?
Regarding mxODBCZopeDA we are currently evaluating this. Because Zope X3 has
a different architecture we would currently have to do a separate product
release solely for Zope X3. We have to wait for architecture to settle before
beginning on this. Hopefully we will be able to write an mxODBCZopeDA for
Zope 3 which will then run on Zope 2.x + FIVE. In the meantime the new
architecture does make it fairly easy for developers to write their own DA
based on mxODBC. It would be useful for us in our planning to hear your
proposed migration strategies.
Charlie
From mal at egenix.com Tue Aug 16 13:14:42 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <4301BC92.3080005@egenix.com>
Daniel W. Adair wrote:
> Hi there!
>
> After migrating from Zope 2.7.0 to 2.8.1, my mxODBCZopeDA connections
> don't work anymore!
>
> System before migration:
> - Debian Sarge
> - Python 2.3.3
> - Zope 2.7.0
> - iODBC
> - mxODBC, mxODBCZopeDA 1.0.8 (licensed)
> (btw, the connection is to an Informix database)
>
> Migration:
> - Zope 2.8.1 needs Python >=2.3.5 so installed Python 2.3.5 with apt-get
> - Built Zope 2.8.1 from source using Python 2.3.5
> - copied directory "mx" over to new Python and "mxODBCZopeDA" over to
> new Zope
> - Debian Sarge ships the UCS4-build of Python 2.3.5 (copying of "mx" in
> the previous step showed an error message), so I installed
> mxODBC(ZopeDA) 1.0.9, as it says on the website.
> - Everything else unchanged.
> - Started Zope, reindexed catalog instances (see Zope 2.8.1/CHANGES),
> everything seemed to be fine. No errors in event.log.
Thanks for the detailed report.
We have been able to reproduce the problem and it seems to
be related to a subtle change in the ZODB used by Zope 2.8.
I've attached a hotfix for the problem. Please let me know
whether it fixes your problem.
To install the hotfix, unzip the attached hotfix ZIP archive
in the Zope directory. It replaces the ZopeDA.pyc file in the
product directory with an updated one.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 16 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
-------------- next part --------------
z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦yè ž,fƇ[s:)yÖµÓÑèµø±ÛM9ÓÍzÎ*SÊ—š¦™bq«b¢óŠ”¢Ííøã][Ê׬
ë ž‹Z½¨¥i¹^R¹™¨¥™©ÚÈb½ë?z§‹¬z»?jÛZržžÛ?ÛM9ÓÍzýïyÓÍß{÷ zx±› mÌè¥çZ×OG¢×âÇm4çO5ëMw÷8©
From bernhard at headnet.dk Wed Aug 17 01:00:21 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Problem with cursor.information
Message-ID:
Hi,
I am currently evaluating mxODBC for a medium size database
integration project where I use Z3.
I want to connect to an Access .mdb file via mdbtools <-> unixODBC <-
> mxODBC.unixODBC <-> Zope3 [freeBSD]
Everything works fine, I can establish a connection and even fetch
records BUT cursor.information contains only tuples where the column
id is empty.
>>> import mx
>>> import mx.ODBC
>>> import mx.ODBC.unixODBC
>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>> dc = dn.cursor()
>>> dc.execute('select * from kvarter')
>>> dc.fetchone()
(50, 'Br\xf8nsh\xf8j')
>>> dc.description
(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
I changed my setup to an iODBC connection, the result is the same,
empty column id's.
When I open the DSN by using isql and execute the same sql statement
as above it returns the column ids properly:
SQL> select * from kvarter
+------------
+-----------------------------------------------------------------------
------------------------------+
| KvarterID |
Kvarter
|
+------------
+-----------------------------------------------------------------------
------------------------------+
| 1 |
Amagerbro
|
Looks as if the problem is on mxODBC's side ...
Is this a bug ?
Has anyone had the same experience ?
I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
therefore I would highly appreciate any help !!
with best regards
Bernhard Snizek
developer
headnet.dk
From mal at egenix.com Wed Aug 17 11:45:18 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To:
References:
Message-ID: <4302F91E.6020408@egenix.com>
Bernhard Snizek wrote:
> Hi,
>
> I am currently evaluating mxODBC for a medium size database
> integration project where I use Z3.
>
> I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
> mxODBC.unixODBC <-> Zope3 [freeBSD]
>
> Everything works fine, I can establish a connection and even fetch
> records BUT cursor.information contains only tuples where the column id
> is empty.
>
>>>> import mx
>>>> import mx.ODBC
>>>> import mx.ODBC.unixODBC
>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>> dc = dn.cursor()
>>>> dc.execute('select * from kvarter')
>>>> dc.fetchone()
> (50, 'Br\xf8nsh\xf8j')
>>>> dc.description
> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>
> I changed my setup to an iODBC connection, the result is the same,
> empty column id's.
>
> When I open the DSN by using isql and execute the same sql statement as
> above it returns the column ids properly:
mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
SQLColAttribute(). Both are mapped to a function in the ODBC
driver, so it looks as if the mdbtools ODBC doesn't work
correctly with SQLDescribeCol() and returns empty strings
instead of the true column name.
Note that you often can't compare the isql tools output
to what mxODBC does: isql is a very simplistic tool
to do som quick and dirty queries, it only knows about
strings, nothing else.
If a query works in isql it doesn't mean that mxODBC will
behave in the same way, simply because mxODBC uses a much
more sophisticated approach to interfacing that tries to
avoid data conversion and copying - providing much better
performance than tools which only do string interfacing.
The downside of this is that, in some cases, it also
causes ODBC driver bugs to show which isql doesn't
reveal.
I'd suggest you report this bug to the mdbtools project.
> SQL> select * from kvarter
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | KvarterID |
> Kvarter
> |
> +------------
> +-----------------------------------------------------------------------
> ------------------------------+
> | 1 |
> Amagerbro
> |
>
> Looks as if the problem is on mxODBC's side ...
>
> Is this a bug ?
> Has anyone had the same experience ?
>
> I will publish my Z3 unixODBCDA as OSS when I got past this hurdle
> therefore I would highly appreciate any help !!
>
> with best regards
>
> Bernhard Snizek
> developer
> headnet.dk
>
>
>
>
>
>
> _______________________________________________________________________
> eGenix.com User Mailing List http://www.egenix.com/
> https://www.egenix.com/mailman/listinfo/egenix-users
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From mal at egenix.com Wed Aug 17 12:40:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4302F91E.6020408@egenix.com>
References:
<4302F91E.6020408@egenix.com>
Message-ID: <4303061C.7090306@egenix.com>
M.-A. Lemburg wrote:
> Bernhard Snizek wrote:
>
>>Hi,
>>
>> I am currently evaluating mxODBC for a medium size database
>>integration project where I use Z3.
>>
>>I want to connect to an Access .mdb file via mdbtools <-> unixODBC <- >
>>mxODBC.unixODBC <-> Zope3 [freeBSD]
>>
>>Everything works fine, I can establish a connection and even fetch
>>records BUT cursor.information contains only tuples where the column id
>>is empty.
>>
>>
>>>>>import mx
>>>>>import mx.ODBC
>>>>>import mx.ODBC.unixODBC
>>>>>mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>dc = dn.cursor()
>>>>>dc.execute('select * from kvarter')
>>>>>dc.fetchone()
>>
>>(50, 'Br\xf8nsh\xf8j')
>>
>>>>>dc.description
>>
>>(('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>
>>I changed my setup to an iODBC connection, the result is the same,
>>empty column id's.
>>
>>When I open the DSN by using isql and execute the same sql statement as
>>above it returns the column ids properly:
>
>
> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
> SQLColAttribute(). Both are mapped to a function in the ODBC
> driver, so it looks as if the mdbtools ODBC doesn't work
> correctly with SQLDescribeCol() and returns empty strings
> instead of the true column name.
Here's the snippet from the mdbtools driver:
SQLRETURN SQL_API SQLDescribeCol(
SQLHSTMT hstmt,
SQLUSMALLINT icol,
SQLCHAR FAR *szColName,
SQLSMALLINT cbColNameMax,
SQLSMALLINT FAR *pcbColName,
SQLSMALLINT FAR *pfSqlType,
SQLUINTEGER FAR *pcbColDef, /* precision */
SQLSMALLINT FAR *pibScale,
SQLSMALLINT FAR *pfNullable)
{
...
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
}
...
and the ODBC specs for the above API:
http://msdn.microsoft.com/library/en-us/odbc/htm/odbcsqldescribecol.asp
As you can see, the driver forgets to update *pcbColName
(NameLengthPtr in the ODBC docs - not sure where mdbtools
got the strange name from) to the value namelen.
Since mxODBC initialized this buffer to 0, it thinks that
the string length is 0 and thus returns an empty string.
SQLColAttributes() in mdbtools has the same problem, BTW.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bernhard at headnet.dk Wed Aug 17 13:06:38 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
I came forward to the same lines in mdbtools code but my knowledge is
poor.
I will attach your comments to my bugreport .. thanx very much
/Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From bernhard at headnet.dk Wed Aug 17 14:19:46 2005
From: bernhard at headnet.dk (Bernhard Snizek)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Problem with cursor.information
In-Reply-To: <4303061C.7090306@egenix.com>
References:
<4302F91E.6020408@egenix.com> <4303061C.7090306@egenix.com>
Message-ID:
Hi again,
following your analysis I added one line and now i get a proper
cursor.description !
if (szColName) {
namelen = MIN(cbColNameMax,strlen(sqlcol->name));
strncpy(szColName, sqlcol->name, namelen);
szColName[namelen]='\0';
*pcbColName = namelen;
}
I will notify the mdbtools project about that ..
Thanx very much for your help I might bother you later towards a
unixODBCDA for zope3 :)
Cheers
Bernhard
On 17/08/2005, at 11.40, M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>
>> Bernhard Snizek wrote:
>>
>>
>>> Hi,
>>>
>>> I am currently evaluating mxODBC for a medium size database
>>> integration project where I use Z3.
>>>
>>> I want to connect to an Access .mdb file via mdbtools <->
>>> unixODBC <- >
>>> mxODBC.unixODBC <-> Zope3 [freeBSD]
>>>
>>> Everything works fine, I can establish a connection and even fetch
>>> records BUT cursor.information contains only tuples where the
>>> column id
>>> is empty.
>>>
>>>
>>>
>>>>>> import mx
>>>>>> import mx.ODBC
>>>>>> import mx.ODBC.unixODBC
>>>>>> mx.ODBC.unixODBC.DriverConnect('DSN=myDSN')
>>>>>> dc = dn.cursor()
>>>>>> dc.execute('select * from kvarter')
>>>>>> dc.fetchone()
>>>>>>
>>>
>>> (50, 'Br\xf8nsh\xf8j')
>>>
>>>
>>>>>> dc.description
>>>>>>
>>>
>>> (('', 4, None, None, 4, 0, 0), ('', 12, None, None, 100, 0, 1))
>>>
>>> I changed my setup to an iODBC connection, the result is the same,
>>> empty column id's.
>>>
>>> When I open the DSN by using isql and execute the same sql
>>> statement as
>>> above it returns the column ids properly:
>>>
>>
>>
>> mxODBC uses SQLDescribeCol() to fetch the column name, isql uses
>> SQLColAttribute(). Both are mapped to a function in the ODBC
>> driver, so it looks as if the mdbtools ODBC doesn't work
>> correctly with SQLDescribeCol() and returns empty strings
>> instead of the true column name.
>>
>
> Here's the snippet from the mdbtools driver:
>
> SQLRETURN SQL_API SQLDescribeCol(
> SQLHSTMT hstmt,
> SQLUSMALLINT icol,
> SQLCHAR FAR *szColName,
> SQLSMALLINT cbColNameMax,
> SQLSMALLINT FAR *pcbColName,
> SQLSMALLINT FAR *pfSqlType,
> SQLUINTEGER FAR *pcbColDef, /* precision */
> SQLSMALLINT FAR *pibScale,
> SQLSMALLINT FAR *pfNullable)
> {
> ...
> if (szColName) {
> namelen = MIN(cbColNameMax,strlen(sqlcol->name));
> strncpy(szColName, sqlcol->name, namelen);
> szColName[namelen]='\0';
> }
> ...
>
> and the ODBC specs for the above API:
>
> http://msdn.microsoft.com/library/en-us/odbc/htm/
> odbcsqldescribecol.asp
>
> As you can see, the driver forgets to update *pcbColName
> (NameLengthPtr in the ODBC docs - not sure where mdbtools
> got the strange name from) to the value namelen.
>
> Since mxODBC initialized this buffer to 0, it thinks that
> the string length is 0 and thus returns an empty string.
>
> SQLColAttributes() in mdbtools has the same problem, BTW.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Aug 17
> 2005)
>
>>>> Python/Zope Consulting and Support ... http://
>>>> www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://
>>>> zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://
>>>> python.egenix.com/
>>>>
> ______________________________________________________________________
> __
>
> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for
> free ! ::::
>
>
From danny at asterisk.co.nz Wed Aug 17 16:26:34 2005
From: danny at asterisk.co.nz (Daniel W. Adair)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
Message-ID: <4302AE6A.3010108@asterisk.co.nz>
Thanks so much!
Hotfix worked, everything fine again.
I don't know what else to say, this is just fantastic response time and
quality!
Cheers,
Danny
M.-A. Lemburg wrote:
> ...
>
> Thanks for the detailed report.
>
> We have been able to reproduce the problem and it seems to
> be related to a subtle change in the ZODB used by Zope 2.8.
>
> I've attached a hotfix for the problem. Please let me know
> whether it fixes your problem.
>
> ...
--
Danny W. Adair
Software Developer
Asterisk Ltd
New Zealand
Talk: +64 9 302 1777
Fax: +64 9 302 1772
Write: dannya@asterisk.co.nz
Browse: www.asterisk.co.nz
Visit: Level Four, Newcall Tower, 44 Khyber Pass Rd, Auckland
Post: PO Box 108018, Symonds St, Auckland
Asterisk
Linux solutions - simple, brilliant, secure.
From mal at egenix.com Wed Aug 17 23:50:06 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <4302AE6A.3010108@asterisk.co.nz>
References: <4302AE6A.3010108@asterisk.co.nz>
Message-ID: <4303A2FE.1080705@egenix.com>
Daniel W. Adair wrote:
> Thanks so much!
>
> Hotfix worked, everything fine again.
> I don't know what else to say, this is just fantastic response time and
> quality!
Thanks :-)
We've put the hotfix up online until we have the 1.0.9 final
release ready:
http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.9-prerelease-py2.3-Hotfix-2005-08-16.zip
This is for Python 2.3 and the 1.0.9 pre-release only. Simply
unzip the above file in the Zope directory. It provides an
updated ZopeDA.pyc file which includes the fix.
> Cheers,
> Danny
>
> M.-A. Lemburg wrote:
>
>> ...
>>
>> Thanks for the detailed report.
>>
>> We have been able to reproduce the problem and it seems to
>> be related to a subtle change in the ZODB used by Zope 2.8.
>>
>> I've attached a hotfix for the problem. Please let me know
>> whether it fixes your problem.
>>
>> ...
Regards,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 17 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From matthias at rubberbiscuit.nl Wed Aug 24 22:57:59 2005
From: matthias at rubberbiscuit.nl (Matthias Pronk)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users]
Message-ID: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Hi!
I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
But the compiler (both gcc 3.3 and 4.0) exit with an error:
------
Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py
install
running install
running build
running build_clib
creating build
creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
[snip output with lots of errors and warnings]
mx/Number/mxNumber/mxNumber.c: At top level:
mx/Number/mxNumber/mxNumber.c:4234: warning:
`mxNumber_BinaryIntegerOperation' defined but not used
mx/Number/mxNumber/mxNumber.c:174: warning: `insint' defined but not
used
mx/Number/mxNumber/mxNumber.c:363: warning: `_mxInteger_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:376: warning: `_mxInteger_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:389: warning: `_mxInteger_FromRational'
defined but not used
mx/Number/mxNumber/mxNumber.c:1088: warning:
`mxInteger_notimplemented1' defined but not used
mx/Number/mxNumber/mxNumber.c:1097: warning:
`mxInteger_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:1106: warning:
`mxInteger_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:1753: warning:
`_mxRational_FromRational' defined but not used
mx/Number/mxNumber/mxNumber.c:1952: warning: `_mxRational_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:2985: warning:
`mxRational_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:2994: warning:
`mxRational_notimplemented3' defined but not used
mx/Number/mxNumber/mxNumber.c:3189: warning: `mxFloat_FromMPZ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3202: warning: `mxFloat_FromMPQ'
defined but not used
mx/Number/mxNumber/mxNumber.c:3241: warning: `_mxFloat_FromInteger'
defined but not used
mx/Number/mxNumber/mxNumber.c:3254: warning: `_mxFloat_FromFloat'
defined but not used
mx/Number/mxNumber/mxNumber.c:3995: warning:
`mxFloat_notimplemented2' defined but not used
mx/Number/mxNumber/mxNumber.c:4004: warning:
`mxFloat_notimplemented3' defined but not used
error: command 'gcc' failed with exit status 1
------
I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
None of these work.
The eGenix base package installed flawlessly.
Any help is appreciated!
Thanks in advance,
- Matthias
From mal at egenix.com Fri Aug 26 15:30:56 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] experimental package on Mac OS X 10.4
In-Reply-To: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
References: <27D601E7-1AD6-472D-8C5A-C19CD8A3A318@rubberbiscuit.nl>
Message-ID: <430F0B80.8050206@egenix.com>
Matthias Pronk wrote:
> Hi!
> I'm trying to compile the experimental package on Mac OS X 10.4 (Tiger).
> But the compiler (both gcc 3.3 and 4.0) exit with an error:
>
> ------
>
> Turing:~/Desktop/egenix-mx-experimental-0.9.0 mp$ python setup.py install
> running install
> running build
> running build_clib
> creating build
> creating build/temp.darwin-8.2.0-Power_Macintosh-2.4
>
> [snip output with lots of errors and warnings]
You've cut away all the interesting stuff (ie. the errors) :-)
> ------
>
> I have Python 2.4.1 and I've tried gcc 3.3 and 4.0.
> None of these work.
>
> The eGenix base package installed flawlessly.
>
> Any help is appreciated!
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 26 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
From bill at big-springs.com Fri Aug 26 17:37:11 2005
From: bill at big-springs.com (Bill Tolbert)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] mxODBC DA for Zope 2.8
Message-ID: <430F7D77.6020509@big-springs.com>
Hey folks, I'm having my first real problem with an egenix product!
I see that last week someone reported a problem with the product on Zope
2.8. I'm having the same problem (see below). Can I get a copy of the patch?
Thanks guys,
Bill
>From charlie at egenix.com Tue Aug 16 13:21:01 2005
From: charlie at egenix.com (Charlie Clark)
Date: Tue Aug 16 12:20:48 2005
Subject: [egenix-users] Help! - mxODBCZopeDA 1.0.9 breaks my Zope 2.8.1
In-Reply-To: <430166F3.7050404@asterisk.co.nz>
References: <430166F3.7050404@asterisk.co.nz>
Message-ID: <20050816122101.10086.14@gorgmenghast.1124177205.fake>
On 2005-08-16 at 06:09:23 [+0200], Daniel W. Adair
wrote:
> Has anyone have similar experiences?
> Where can I look for a solution?
>
> It seems to me like something that needs to be persistently stored in
> the ZODB isn't...
> Was mxODBCZopeDA thoroughly tested with Zope 2.8.1 and the new ZODB version?
>
> This is for a client, and they need to use the database connection every
> day (including today :-().
> Please help.
Danny,
thanks for pointing this out to us. The problem is indeed related to the ZODB
change which we hadn't picked up on our tests. We will send you a patched
.pyc of the DA.
From erich.birrer at birrer-edv.ch Mon Aug 29 21:24:38 2005
From: erich.birrer at birrer-edv.ch (Erich Birrer-Uster)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] ProgrammingError
Message-ID: <20050829182437.4461F61BD4@mail.egenix.com>
Hallo
Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
Site Error
An error was encountered while publishing this resource.
mx.ODBC.Error.ProgrammingError
Sorry, a site error occurred.
Traceback (innermost last):
? Module ZPublisher.Publish, line 163, in publish_module_standard
? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
? Module ZPublisher.Publish, line 108, in publish
? Module Zope.App.startup, line 226, in abort
? Module ZODB.Transaction, line 134, in abort
? Module Shared.DC.ZRDB.TM, line 63, in abort
? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
1094)
________________________________________
Troubleshooting Suggestions
? The URL may be incorrect.
? The parameters passed to this resource may be incorrect.
? A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.
If the error persists please contact the site maintainer. Thank you for your patience.
Meine Installation sieht wie folgt aus:
Zope Version (unreleased version, python 2.3.3, win32)
Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
System Platform win32
SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
ZOPE_HOME C:\Programme\Plone 2\Zope
INSTANCE_HOME C:\Programme\Plone 2\Data
CLIENT_HOME C:\Programme\Plone 2\Data\var
Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
Connection Id w-e3000
Connection Title e3000-DB
Database Connection Source DSN=webudc01
ODBC Manager/Driver Platform Default
Connection Information Connected database: Pervasive.SQL, 7.94
ODBC driver: W3ODBCCI.DLL, 7.82.197
Database Timezone Local Time Zone
Connection Options
* Database Warnings are reported as Python exceptions.
* Connection uses transactions.
* Time columns are returned as DateTime values.
* Date/time columns are returned as Zope DateTime values.
* Short integers are fetched as short integers.
* NULL values are returned as None.
* Scale 0 floats are converted to integers.
* The first available result set is fetched in queries.
Connection Pool Pool size: 20
Physical connections: 1 open
Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
mxODBC Zope DA 1.0.8
Wo beginne ich am Besten mit der Fehlersuche?
Besten Dank f?r eure Tipps
Erich
From mal at egenix.com Mon Aug 29 22:08:44 2005
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri Mar 31 16:34:15 2006
Subject: [egenix-users] ProgrammingError
In-Reply-To: <20050829182437.4461F61BD4@mail.egenix.com>
References: <20050829182437.4461F61BD4@mail.egenix.com>
Message-ID: <43135D3C.2080800@egenix.com>
[egenix-users ist eine englischsprachige Liste, daher die Anwort
in Englisch]
> Ab und zu (aber leider immer wieder) tritt bei einer Anwendung folgender Fehler auf:
>
> Site Error
> An error was encountered while publishing this resource.
> mx.ODBC.Error.ProgrammingError
> Sorry, a site error occurred.
> Traceback (innermost last):
> ? Module ZPublisher.Publish, line 163, in publish_module_standard
> ? Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
> ? Module ZPublisher.Publish, line 108, in publish
> ? Module Zope.App.startup, line 226, in abort
> ? Module ZODB.Transaction, line 134, in abort
> ? Module Shared.DC.ZRDB.TM, line 63, in abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 1064, in _abort
> ? Module Products.mxODBCZopeDA.ZopeDA, line 939, in errorhandler
> ProgrammingError: ('HY000', 9114, '[Pervasive][ODBC Client Interface][Client LNA]Your connection to the server is no longer working.
> To continue, disconnect from the data source and re-connect again. Contact your system administrator if you still need assistance.',
> 1094)
We have had similar reports from users with other driver/database
combinations. Unfortunately, there's nothing much we can do
about it since these errors are usually related to network
or timeout problems with the ODBC driver and database.
In the next release, we'll map the HY000 error to an OperationalError
which will then cause the Zope DA to try an automatic reconnect.
________________________________________
> Troubleshooting Suggestions
> ? The URL may be incorrect.
> ? The parameters passed to this resource may be incorrect.
> ? A resource that this resource relies on may be encountering an error.
> For more detailed information about the error, please refer to error log.
> If the error persists please contact the site maintainer. Thank you for your patience.
>
>
> Meine Installation sieht wie folgt aus:
>
> Zope Version (unreleased version, python 2.3.3, win32)
> Python Version 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)]
> System Platform win32
> SOFTWARE_HOME C:\Programme\Plone 2\Zope\lib\python
> ZOPE_HOME C:\Programme\Plone 2\Zope
> INSTANCE_HOME C:\Programme\Plone 2\Data
> CLIENT_HOME C:\Programme\Plone 2\Data\var
> Network Services ZServer.HTTPServer.zhttp_server (Port: 8080) ZServer.HTTPServer.zhttp_server (Port: 80)
>
> Connection Id w-e3000
> Connection Title e3000-DB
> Database Connection Source DSN=webudc01
> ODBC Manager/Driver Platform Default
> Connection Information Connected database: Pervasive.SQL, 7.94
> ODBC driver: W3ODBCCI.DLL, 7.82.197
> Database Timezone Local Time Zone
> Connection Options
> * Database Warnings are reported as Python exceptions.
> * Connection uses transactions.
> * Time columns are returned as DateTime values.
> * Date/time columns are returned as Zope DateTime values.
> * Short integers are fetched as short integers.
> * NULL values are returned as None.
> * Scale 0 floats are converted to integers.
> * The first available result set is fetched in queries.
> Connection Pool Pool size: 20
> Physical connections: 1 open
> Connection State connected (since 2005/08/29 20:07:46.640 GMT+2)
> mxODBC Zope DA 1.0.8
>
> Wo beginne ich am Besten mit der Fehlersuche?
>
> Besten Dank f?r eure Tipps
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 29 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::