[egenix-users] ODBC encoding problems

Martijn Pieters mj at zopatista.com
Sun Oct 28 23:01:46 CET 2007


On 10/28/07, M.-A. Lemburg <mal at egenix.com> wrote:
> > No 'client charset' entry is set.
>
> That should result in Latin-1 being used as default.

Indeed, and the isql client has no problem showing encoded results.

> >     +-------------------------+-----------+------------+---------+
> >     | COLUMN_NAME             | TYPE_NAME | LENGTH     | NULLABLE|
> >     +-------------------------+-----------+------------+---------+
> >     | contact_id              | int       | 4          | 0       |
> >     | name                    | varchar   | 49         | 0       |
> >     | department              | varchar   | 39         | 1       |
> >     | userdef_id              | int       | 4          | 1       |
> >     +-------------------------+-----------+------------+---------+
> >
> > The offending columns are claimed to be simple varchars.
>
> Those shouldn't really cause the warnings you are seeing.
> We have seen such warnings in tests that try to store
> binary data in a NCHAR column, but not with VARCHAR columns.
>
> Do you get the warning when reading from the database or
> writing to it ?

Reading. I have no write access.

> Do have the offending strings available ? We could
> then construct a test case to try against our SQL Server
> installation.

Here are the first 2 rows as comma-separated values, which happen to
be public company names.
2, SuperOffice Norge AS, Østnorsk, 2
3, Norsk Jazzforum, Østnorsk, 1453

In case email encoding gets mucked up, that's 2 times O with /
(unicode 00D8) in the 'department' column (don't ask why the
department column holds a region in Norway).

-- 
Martijn Pieters


More information about the egenix-users mailing list