From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | "Ben Trewern" <ben(dot)trewern(at)_nospam_mowlem(dot)com>, <pgsql-odbc(at)postgresql(dot)org> |
Subject: | Re: Bug or not about ASCII and Multi-Byte character set |
Date: | 2005-08-19 12:24:09 |
Message-ID: | E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC9B55@ratbert.vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
> -----Original Message-----
> From: pgsql-odbc-owner(at)postgresql(dot)org
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Ben Trewern
> Sent: 15 August 2005 13:44
> To: pgsql-odbc(at)postgresql(dot)org
> Subject: Re: [ODBC] Bug or not about ASCII and Multi-Byte
> character set
>
> I'd like to make a few points on this issue.
>
> 1. This problem should be mentioned in the FAQs as largely
> as possible as
> it is difficult to rectify if you have fallen into this trap.
Agreed - I'll do that.
> 2. If you do have data in SQL_ASCII the old ODBC driver
> worked, PgAdmin III
> works, Delphi and zeoslib works, I understand why there may
> be a problem but
> is it not possible to make the new 8.x work?
Actually, pgAdmin doesn't always work. If you try to insert Japanese
characters into an SQL_ASCII database it errors for example. Try it with
a Unicode database and it's fine.
Also, the old ODBC driver didn't always work either. If you check the
archives, you'll find people complaining of the same problem with the
non-libpq drivers.
> 3. Correct me if I'm wrong but SQL_ASCII is PostgreSQL's
> default encoding.
> If this isn't sorted out then we'll see lots more of these
> messages for
> help.
>
> 4. I'd like to disagree with your "DO NOT USE ASCII FOR
> NON-ASCII DATA" as
> if you read any of Tom Lanes many messages on the subject.
> Here's a quote:
>
> "The SQL_ASCII setting isn't an
> encoding, really; it's a declaration of ignorance. In this setting
> the server will just store and regurgitate whatever character strings
> you send it. This will work fine, more or less, if all your clients
> use exactly the same encoding and you don't care about functions like
> upper()/lower()"
Which is fine - however, as Tom also says:
"If you flip between SQL_ASCII and other settings, on either end,
without
clearly understanding what's happening, you're likely to get very
confused."
Which is pretty much what seems to be happening - ppl are using a
Unicode ODBC driver, and 7bit ascii data that cannot be properly
represented gets converted to '?'. They don't necessarily realise that
apps like Access will usually retrieve data as SQL_C_WCHAR if they can,
thus forcing a conversion to Unicode.
Regards, Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Fradkin | 2005-08-19 12:40:15 | Re: Bug or not about ASCII and Multi-Byte character set |
Previous Message | Marc Herbert | 2005-08-19 09:37:32 | Re: Bug or not about ASCII and Multi-Byte character set |