oracle replaces ISO-8859-1 characters with question marks

[Noah]

The problem I'm having is that whenever a user enters
accented characters character into a form field the characters
are getting stored as question marks in the database.
For example, "façade" (c with cedilla) is stored as "fa?ade"
Does anyone have any idea how to fix this problem?

My page has a meta header to set Content-Type:
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
I traced the input to the PHP form submission page.
I printed the posted form fields and the characters
come through as expected, so I'm pretty sure that this
is a problem with the database side.
I'm using Oracle 10g running on Linux. I'm using PEAR db.
My update query is simple and straightforward :
UPDATE release SET message='façade ' WHERE release_id=5831 ;
I have included my Oracle NLS database parameters.

Yours,
Noah

SQL> select * from NLS_DATABASE_PA RAMETERS;

PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENC Y AMERICA
NLS_NUMERIC_CHA RACTERS .,
NLS_CHARACTERSE T WE8ISO8859P1
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUA GE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_F ORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FOR MAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_T Z_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURREN CY $
NLS_COMP BINARY
NLS_LENGTH_SEMA NTICS BYTE
NLS_NCHAR_CONV_ EXCP FALSE
NLS_NCHAR_CHARA CTERSET AL16UTF16
NLS_RDBMS_VERSI ON 10.1.0.2.0

[Andy Hassall]

On 22 Feb 2005 15:25:15 -0800, "Noah" <no**********@g mail.com> wrote:

The problem I'm having is that whenever a user enters
accented characters character into a form field the characters
are getting stored as question marks in the database.
For example, "façade" (c with cedilla) is stored as "fa?ade"
Does anyone have any idea how to fix this problem?

My page has a meta header to set Content-Type:
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
You'd be better off with a proper HTTP header, but anyway...
I traced the input to the PHP form submission page.
I printed the posted form fields and the characters
come through as expected, so I'm pretty sure that this
is a problem with the database side.
I'm using Oracle 10g running on Linux. I'm using PEAR db.
My update query is simple and straightforward :
UPDATE release SET message='façade ' WHERE release_id=5831 ;
Hopefully you're not actually running that - you're using bind variables in
the real thing, right?
I have included my Oracle NLS database parameters.

SQL> select * from NLS_DATABASE_PA RAMETERS;

PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERS ET WE8ISO8859P1

OK, so you can definitely store the things, so it's a client issue.

What's the NLS_LANG environment variable set to? This the most likely suspect
- if set wrongly it can easily give the problems described.

What's the definition of the table - message is just a VARCHAR2, right?

--
Andy Hassall / <an**@andyh.co. uk> / <http://www.andyh.co.uk >
<http://www.andyhsoftwa re.co.uk/space> Space: disk usage analysis tool

[Noah]

Great! Everything worked from the command-line sqlplus
when I set the environment variable:
export NLS_LANG=americ an_america.WE8I SO8859P1
So it was a client issue. But when I tried to set the same
environment variable from PHP using:
putenv("NLS_LAN G=american_amer ica.WE8ISO8859P 1"));
the accented chars still get replaced, but now they are replaced with
upside-down Spanish question marks. Weird.

It works fine if I set the environment variable before I start Apache.
I wish it would work from the code side, but at least it works.

Yours,
Noah