Re: Unicode and Sybase univarchar



Alexander Foken wrote:
On 04.06.2010 15:41, Dave Rolsky wrote:
On Fri, 4 Jun 2010, Alexander Foken wrote:
That's why I proposed to switch to DBD::ODBC: It is well tested and
supports Unicode as good as the ODBC driver does.

And as I said in private email, that's not really feasible for us.
Yes, it would cause you a lot of work, starting by distributing an ODBC
manager and an ODBC driver. Perhaps too much work. Think of it as a last
resort.

But for patching Unicode support into DBD::Sybase, DBD::ODBC could be
helpful, both by showing how to patch DBD::Sybase, and by providing a
Unicode-aware way to the database on the development machine.

Now you "just" need to find someone who is willing and has the time
to patch DBD::Sybase ... ;-)

Which is why I'm hoping we can pay Michael to work on this.
Throwing money at the problem is definitly a good idea! And it would be
great if that work would end on CPAN (and not in a secret private branch).
Clearly, he's the most qualified.

Otherwise, I might have to do this, which is a scary thought.
Well, I also was scared by DBD::ODBC, and I must admit that I still
don't understand all of it. I'm still happy that MJE took over the
stalled DBD::ODBC development and improved my patch (and many other
parts of DBD::ODBC).

A first step to patching DBD::Sybase would be like my first step with
DBD::ODBC: Just make binding input parameters and fetching results work
with Unicode. Don't care about Unicode in the SQL statement (use
placeholders, so you don't need Unicode there), don't care about binding
output parameters, connect strings, user names, passwords, private
functions. "Steal" the Unicode tests from DBD::ODBC and make DBD::Sybase
pass those tests without breaking the existing tests.


Alexander


Just a little note on copying the unicode tests in DBD::ODBC. There is
nothing in particular wrong with them but they can cause some drivers
problems because they use functions on parameters and sometimes the
driver cannot (or fails) to work out the correct type of the parameter:

e.g.,

SELECT ? as roundtrip, length(?) as roundtriplen

Some drivers (MS SQL Server in particular) attempts to rearrange the
above SQL to a select on 2 columns in the database to work out the
parameter types. In the above case there are no real database columns
and it fails.

Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
.



Relevant Pages

  • Re: DBD::ODBC and character sets
    ... perl script is utf-8? ... FreeTDS. ... There is no Unicode option for FreeTDS. ... application calls the Wide functions and the driver has the Wide ...
    (perl.dbi.users)
  • Re: DBD::ODBC and character sets
    ... perl script is utf-8? ... FreeTDS. ... There is no Unicode option for FreeTDS. ... application calls the Wide functions and the driver has the Wide ...
    (perl.dbi.users)
  • New test release 1.16_3 of DBD::ODBC
    ... Disallow building with iODBC if it is a unicode build. ... Fix bug in out connection string handling that attempted to use an out ... but cannot describe all parameters e.g., MS SQL Server ODBC driver ...
    (perl.dbi.users)
  • Re: Unicode and Sybase univarchar
    ... supports Unicode as good as the ODBC driver does. ... Yes, it would cause you a lot of work, starting by distributing an ODBC manager and an ODBC driver. ... But for patching Unicode support into DBD::Sybase, DBD::ODBC could be helpful, both by showing how to patch DBD::Sybase, and by providing a Unicode-aware way to the database on the development machine. ... And it would be great if that work would end on CPAN (and not in a secret private branch). ...
    (perl.dbi.users)
  • Re: Converting Unicode
    ... The real question is how are you going to pass UTF-8 characters to the driver. ... Remember that System.String is *always* Unicode, so unless you have a way to pass a byte array, you might have hard time passing a UTF-8 string. ...
    (microsoft.public.dotnet.languages.csharp)