[egenix-users] Two bugs in mxODBC: storing empty string and unicode string

[M.-A. Lemburg]

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
customers.

> 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.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

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.
> http://msdn2.microsoft.com/en-gb/library/ms716246.aspx
> 
>> 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
> patch.
> 
> Thanks,