[egenix-users] Two bugs in
mxODBC: storing empty string and unicode string
mal at egenix.com
Tue Aug 14 14:18:38 CEST 2007
On 2007-08-14 11:28, Harri Pesonen wrote:
> Great! How about mxODBC 2, is it supported at all, I can't find the
> download anymore.
mxODBC 2.0 is no longer being actively maintained, however we still
provide individual support based on support tickets for existing
> I guess that we need upgrade: "If you'd like to
> upgrade your mxODBC 2.0 licenses to version 3.0, please contact our
> sales team."
I'll forward your request.
Professional Python Services directly from the Source (#1, Aug 14 2007)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
> -- Harri
> -----Original Message-----
> From: M.-A. Lemburg [mailto:mal at egenix.com]
> Sent: 14. elokuuta 2007 12:08
> To: Harri Pesonen
> Cc: egenix-users at lists.egenix.com
> Subject: Re: [egenix-users] Two bugs in mxODBC: storing empty string and
> unicode string
> Some more investigation showed that even though the type binding
> was set to SQL (the ODBC driver providing the type information),
> when using .executedirect() the driver does not provide the
> type information. mxODBC uses Python type binding in such a case.
> On 2007-08-14 08:04, Harri Pesonen wrote:
>> I'm sure that you'll find out that you are using nchar(N) data type,
>> where N is calculated from the number of bytes in the unicode string,
>> not number of characters.
> The length information to use in ODBC APIs is a weak spot in the ODBC
> standard documentation... in some places it refers to byte counts,
> in others to code point counts and they aren't clear at all about
> which to use, see e.g.
>> This is Microsoft SQL Server ODBC driver, so this is the standard. :-)
> Well, I wouldn't be so sure about this. Especially with respect to
> Unicode handling, the SQL Server's ODBC driver tends to have a
> very special interpretation. Things get even more complicated on
> 64-bit platforms.
>> One more thing: You could easily fix this problem by using nvarchar
>> instead of nchar data type. Nchar(N) requires that there are exactly N
>> characters, and SQL Server ODBC driver will add spaces if needed.
>> Nvarchar(N) would not ever add spaces.
> That's what we've done now and it fixes the problem even when
> using .executedirect().
> However, that's just the SQL Server ODBC driver. We'll have to
> test this with other ODBC drivers as well before releasing a
More information about the egenix-users