Inconsistency while storing Spanish Characters in Devl Vs Prod Databases:

Question

Hi there,
We have setup dev and prod database instances with the same NLS Characterset settings,
However, when a Spanish character is saved in the devl instance,
the character is saved to the database correctly.
However the same character when saved in prod, is stored as ampersand, pound, 0255; not á.
Although the character displays correctly via sqldeveloper as well as in the reports,
any ideas as to why there is inconsistency in the behavior.
SQL> select instance_name from V$instance;
INSTANCE_NAME
utf8devl
SQL> select * from nls_database_parameters
where parameter like '%CHARACTERSET';
PARAMETER                VALUE
NLS_CHARACTERSET          AL32UTF8
NLS_NCHAR_CHARACTERSET          AL16UTF16
SQL> desc tblpersoninfo
Name Null? Type
ACTIVE VARCHAR2(1)
ID NOT NULL NUMBER(9)
LAST_NAME VARCHAR2(255)
FIRST_NAME VARCHAR2(255)
MI VARCHAR2(12)
SQL>select last_name from tblpersoninfo where id=2;
LAST_NAME
xxxxx     á
SQL> select instance_name from V$instance;
INSTANCE_NAME
utf8prod
SQL> select * from nls_database_parameters
where parameter like '%CHARACTERSET';
PARAMETER                VALUE
NLS_CHARACTERSET          AL32UTF8
NLS_NCHAR_CHARACTERSET          AL16UTF16
SQL>select mi from tblpersoninfo where id=2;
MI
á
(although the character renders properly here, it is saved as ampersand, pound, 0255;)
SQL>select length(mi) from tblpersoninfo where id=2;
LENGTH(MI)
6
when I was expecting 1 as the result for the above query.
best regards,
NK
Edited by: NK on Jan 13, 2012 10:03 AM
Edited by: NK on Jan 13, 2012 10:04 AM

Answer 1

NK wrote:
The programmer who has reported this problem is using the same application just switching between the 2 environments;
á Typ=1 Len=6 CharacterSet=AL32UTF8: 26,23,32,32,35,3bI guess Srini is correct in asking for the process in which this is stored. E.g. What does above "just switching" actually involve?
Above characters & #225 ; implies "html character entities" input, which means prod does not behave same as dev. (Oracle would not, by itself, cause that kind of "conversion".)
Investigate input at client side (e.g. web server form).
Note, to clarify for readers of this thread: the rendering of the html entity to character glyph (á) occurs in forum post.
Edit:
added a missing and crucial "not"
Edited by: orafad on Jan 13, 2012 8:31 PM
Edited by: orafad on Jan 13, 2012 8:33 PM
Edited by: orafad on Jan 13, 2012 9:19 PM