[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