Andy,
Can you check what got into the database ? You can do a :
SELECT .. DUMP(column, 16) FROM ...
This will give you a hex dump of the physical contents of the column.
If you have your NLS_LANG and the database both using the same characterset, then
Oracle will pass on all characters untranslated. This is the so even if the
characterset is 7 bit and the characters have the 8th bit set !
So, your problem must come from elsewhere, not from Oracle. It couldn't be simply a
display problem ? Like if you use a terminal emulator configured for 7 bit and
stripping the 8th ? I have seen that happen before.
Brgds,
Mark
----- Original Message -----
From: "Tim Bunce" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2001 11:52 PM
Subject: (Fwd) Further Oracle Character Set Issues
> ----- Forwarded message from Andy Brick <[EMAIL PROTECTED]> -----
>
> From: Andy Brick <[EMAIL PROTECTED]>
> To: Tim Bunce <[EMAIL PROTECTED]>
> Subject: Further Oracle Character Set Issues
> Date: Mon, 30 Apr 2001 22:42:05 +0100
> In-Reply-To: <[EMAIL PROTECTED]>
>
> Hi
>
> I have my Perl script working fine on NT and Oracle 8.1.5-ish now.
> International characters from ISO8859-1 work fine, and I'm translating the
> extra Window 1252 characters without a hitch.
>
> However, on Linux, with the same script, same data and same database, the
> eighth/top bit of each character gets reset and lost in Oracle. Oracle is
> using WE8ISO8859P1 for both NLS character sets, and the fact that the file
> is Code Page 1252 encoded shouldn't be an issue - the extra 1252 characters
> are translated by the Perl and the rest is compatible with WE8ISO8859P1 -
> plus it works on NT.
>
> I've dumped the hex of the string I am passing to Oracle and it has the
> eighth bit there, with no hassles.
>
> Am I missing something here ?
>
> Any and all help greatly appreciated !!
>
> Andy Brick
> [EMAIL PROTECTED]
>
> ----- End forwarded message -----
>
