Actually - the db always stores bytes - the US7ASCII characterset only
defines 127 characters (7 bits), but as no conversion is done when
client and database charactersets are the same, characters are stored
and retrieved OK.

I checked - WE8MSWIN1254 is not installed, so I tried with
WE8MSWIN1252. I ran a test and the characters still wont convert. I'm
starting to think this has more to do with an MS Office configuation,
not ODBC directly.

Try "select dump(your_characterfield), your_characterfield from table"
and post the result.

Sorry Frank I don't exactly understand,
should I try:
select dump(srsk_frch_dsc),srsk_frch_dsc from wh_srsk;

wh_srsk is a table that contains an English Description and French
Description.
The french description field name is srsk_frch_dsc

Here is the Dump If I did this correct
DUMP(SRSK_FRCH_DSC) SRSK_FRCH_DSC
Typ=1 Len=6: 70,97,105,98,108,101 Faible
Typ=1 Len=14: 80,97,115,32,97,117,32,100,111,115,115,105,101,114 Pas au
dossier
Typ=1 Len=14: 80,97,115,32,97,117,32,100,111,115,115,105,101,114 Pas au
dossier
Typ=1 Len=14: 80,97,115,32,97,117,32,100,111,115,115,105,101,114 Pas au
dossier
Typ=1 Len=5: 77,111,121,101,110 Moyen
Typ=1 Len=14: 80,97,115,32,97,117,32,100,111,115,115,105,101,114 Pas au
dossier
Typ=1 Len=14: 80,97,115,32,97,117,32,100,111,115,115,105,101,114 Pas au
dossier
Typ=1 Len=16:
77,111,100,233,114,233,109,101,110,116,32,233,108, 101,118,233 Modiriment
ilevi
Typ=1 Len=14: 80,97,115,32,97,117,32,100,111,115,115,105,101,114 Pas au
dossier
Typ=1 Len=5: 201,108,101,118,233 Ilevi
Typ=1 Len=14: 80,97,115,32,97,117,32,100,111,115,115,105,101,114 Pas au
dossier

The Records with the problem have the work Modiriment ilevi and Ilevi.
They should be Modérément élevé and Élevé respectively

Alt255 schreef:
> Sorry Frank I don't exactly understand,
> should I try:
> select dump(srsk_frch_dsc),srsk_frch_dsc from wh_srsk;
>
Yup.

> Typ=1 Len=16:
> 77,111,100,233,114,233,109,101,110,116,32,233,108, 101,118,233 Modiriment
> ilevi
> The Records with the problem have the work Modiriment ilevi and Ilevi.
> They should be Modérément élevé and Élevé respectively
>
Well, the database has some extended characters...
77 - M (0x4D)
111 - o (0x6F)
100 - d (0x64)
233 - ? (0xE9)

As the first three characters are all in the range, below 0x80
(or 128), they are defined in the standard ASCII table.
Most fonts will map that to the same graphic representation, being
Mod (however: not all fonts will do that - think Windings...).

The situation for codes, higher than 0x7F fall in the "extended
ASCII set", for which there is not standard...
Your current from end maps 0xE9 to i (0x069).
i = 0x69 = 01101001
é = 0xE9 = 11101001

See the pattern? You loose your MSB; you do character conversion!
Set all to US7ASCII, and you have no conversion!

Then, take a front end, that actually can display the special
characters; this email client can, so I can cut-n-paste 2 sessions:

SQL> select chr(233) from dual;
C
-
é

SQL> select chr(233) from dual;
C
-
Θ

Both were done against the same database; both were done from
a MS Windows client:
the upper is a terminal emulator, that supports UTF-8 (and thus
extended characters), the lower is the Command Line Interface,
that uses Fixed System font.
Change the font to Lucinda, and the active code page to 1252,
(chcp 1252) and a new session in the CLI will show the é correctly.

--
Regards,
Frank van Bortel

Top-posting is one way to shut me up...

>NLS_CHARACTERSET US7ASCII
>NLS_RDBMS_VERSION 8.1.7.3.0

Just to add a bit to what Jim and Frank said, you _need_ to change your
character set to an 8 bit one. If you use exp/imp to do this, you will
be messed up. In later versions of Oracle there are supported ways to
fix this, but in 8i you should plan to unload all the data to a flat
file and then reload into a db with a proper characterset (and
preferably a more recent Oracle version). Of course, if you've gotten
to the point of understanding when and how character translations are
made you may be able to do it with exp/imp - I believe some googling of
this group and poking about in metalink may show how, too.

Your data warehouse has what may be called "deferred maintenance" that
needs to be performed, how exactly you do that depends on the totality
of it all - how many tables actually have these characters, how big
they are, if you have the data elsewhere so you can reload it, rate of
loading, how clued your management is to the importance of maintenance
and upgrades... 7 bit ascii is the default on db creation, this may
ultimately be blamed on whoever created the database, if you need to
point fingers.

jg
--
@home.com is bogus.
http://www.jgc.org/blog/2006/05/ther...-spam-and.html

I have had my company escalate this to Microsoft, see if they can help,
I suspect it's a problem on thier side

Alt255 <alt255.2005@gmail.com> wrote:
> I have had my company escalate this to Microsoft, see if they can help,
> I suspect it's a problem on thier side

From the previous discussion it has become quite clear that the problem
in this case is not Microsoft's.

It is that you entered 8-bit characters into a database with the 7-bit
character set. You must fix this.

I see two things that you could try (and I hope that someone will correct
mw if I am wrong):
- Attempt to change the database character set to match the character set
in which the data you entered were encoded. Maybe that will work.
- Create a new database with a correct database character set, somehow
get the data out from your current database (not sure how) and insert
them into the new database.

Yours,
Laurenz Albe

Hi Laurenze,

I guess I have to elaborate on my situation. I'm a contractor for a
large organization using MS Access to create reports from a Oracle Data
Warehouse used through-out the corporation. I am the System Analyst
here and cannot create a new database ( though I have my own sandbox).
I must use the existing tables with the French fields. I would create a
local table in Access, but some of our product tables ( with French
descriptions) have 50,000 records changing regularly.
I have been considering using Impromptu to create a daily extract, and
then load this into an Access table, but as we know this is a poor
approach ( but if I cannot resolve this then I must).

I find it baffling that Impromptu can report the correct characters,
but MS access and Excel cannot. It was this line of thinking that made
me request a Microsoft resource.

I hate wasting peoples time, Laurenz, are you certain MS cannot help? I
was in contact with our Senior Oracle DBA initially for a solution but
he couldn't help. I'm thinking I should show him this thread, maybe
his knowledge and your suggestions can get this resolved.

"Laurenz Albe" <invite@spam.to.invalid> wrote in message
news:1147855078.177507@proxy.dienste.wien.at...
> Alt255 <alt255.2005@gmail.com> wrote:
> > I have had my company escalate this to Microsoft, see if they can help,
> > I suspect it's a problem on thier side
>
> From the previous discussion it has become quite clear that the problem
> in this case is not Microsoft's.
>
> It is that you entered 8-bit characters into a database with the 7-bit
> character set. You must fix this.
>
> I see two things that you could try (and I hope that someone will correct
> mw if I am wrong):
> - Attempt to change the database character set to match the character set
> in which the data you entered were encoded. Maybe that will work.
> - Create a new database with a correct database character set, somehow
> get the data out from your current database (not sure how) and insert
> them into the new database.
>
> Yours,
> Laurenz Albe
You are correct. The export is going to have to be to text files connected
with the same character set as the database. Then change the database
character set and reimport the text files.(export/import won't work)
Jim