ORACLE pb after migrating 3.1 to 5.2

[Sébastien]

Hi,

We just install CTD 5.2 and we have character accent problem with Oracle 10g

CTD 3.1 - SqlTalk version 8 - sqlora32.dll version 3.0.0.13322

select * from t_activite ;
2 Pré-Traitement 0 0 0 0 0 0 1 1 1 0 1 1 1 1 0 0 1
5 Co-incinération 0 1 0 1 0 0 1 0 0 0 0 1 1 1 1 0 1



CTD 5.2 - SqlTalk version 5.2.1 Build 15186 - sqlora32.dll version 5.2.1.16227

select * from t_activite ;
2 Pri-Traitement 0 0 0 0 0 0 1 1 1 0 1 1 1 1 0 0 1
5 Co-inciniration 0 1 0 1 0 0 1 0 0 0 0 1 1 1 1 0 1

Thanks for help

Sébastien

[Sébastien]

Should I submit this problem somewhere else?

Did i miss same problem in other topics ?

Thanks a lot

[Jeff Luther]

How about a SQL script that can be run. Should include create, insert some rows, select, etc. Whatever is need to show the complete issue. Sorry, but I have no idea what this means:

2 Pré-Traitement 0 0 0 0 0 0 1 1 1 0 1 1 1 1 0 0 1
5 Co-incinération 0 1 0 1 0 0 1 0 0 0 0 1 1 1 1 0 1

so I need to see something in a SQL script running in SQLTalk.

[Sébastien]

Hi,

thanks for response.

With the same ORACLE database (NLS_LANG : AMERICAN_AMERICA.US7ASCII)

With CTD 3.1 (sqlTalk version 8 - sqlora32.dll version 3.0.0.13322)
--> select 'ééé' from dual ; --> Result : ééé

With CTD 5.2 (SqlTalk version 5.2.1 Build 15186 - sqlora32.dll version 5.2.1.16227)
--> select 'ééé' from dual ; --> Result : eee

We migrate in 5.2 and have this problem in all our applications. Compiling is ok, runtime is ok but all accents have disapeared.

TEST in 5.2
create table t_test (a varchar2 (20) ) ;
insert into t_test values ('ééé') ;
commit ;
select * from t_test ;
--> eee

TEST in 3.1
select * from t_test ;
--> eee

insert into t_test values ( 'èèè' ) ;
commit ;
select * from t_test ;
--> eee
--> èèè

Back in 5.2
select * from t_test ;
--> eee
--> hhh

We lost accent inserted with V5.2.

We don't lost accent in 3.1 but V5.2 doesn't show them and accent characters are replaced by other character.

Same problem if we create the table with ctd3.1 first.

It looks like sqlora32.dll doing a wrong conversion

We assure our client that migrating is very easy and quick. It's true, we migrate our sources code and qrp (300 qrp, 100M of source code) very quickly and easily, but we will have to stop migrating if we can't find our accent with new version.

Thanks for you help