IBM OLE DB Provider for DB2 Codepage error.

[Amber]

We use the IBM OLE DB Provider for DB2 to connect to a database on AIX
5.2 from SQL Server Integration Service. But there is some codepage
problems. On AIX we use ISO-8859-1, when use DB2 CLP, we should first
set DB2CODEPAGE property to 819(using db2set DB2CODEPAGE=819). Our OLE
DB Connectionstring is as follows:
"Data Source=MIGDB;User ID=fmadmin;Provider=IBMDADB2.1;Persist Security
Info=True;Location=;Extended Properties="

We guess some magic properties should be added to the extended
properties section, but don't know which one ,we have tried
DB2CODEPAGE/IBM CCSID, neither works.

[Amber]

Are there any IBM Guys,^_^

[Serge Rielau]

Amber wrote:

Are there any IBM Guys,^_^

There are, but as far as I am concerned I'm codepage illiterate...

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

[Amber]

Serge Rielau
Glad to see you again, can you get any from your colleague,^_^.
In the Microsoft SSIS forum it seems this is a common problem.

[Serge Rielau]

Amber wrote:

Serge Rielau
Glad to see you again, can you get any from your colleague,^_^.
In the Microsoft SSIS forum it seems this is a common problem.

Amber,

Here is a comment from back-stage:
I have not really come across this issue in the past with OLE DB, as
most OLE DB apps use the WCHAR type - basically making OLE DB a unicode
app. It may be possible that DB2CODEPAGE is messing up OLE DB, somehow
causing a (lossy?) conversion to some other codepage, then the corrupted
data gets converted to unicode. I would recommend unsetting
DB2CODEPAGE, and if that does not resolve the issues, then this should
go through service so they can look at what specific codepoints are
getting mangled.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

[Amber]

Yes, in order to use CLP we have set DB2CODEPAGE to 819, I will try
unset this property next morning. In the DB2 database on an AIX box,
developers have heavylly used varchar to hold chinese strings. Now we
try the OLE DB provider, ADO.NET/ODBC and ADO.NET/OLE DB provider in
SSIS ,everything works well except those strings. That's really
strange.

[Serge Rielau]

Amber wrote:

Yes, in order to use CLP we have set DB2CODEPAGE to 819, I will try
unset this property next morning. In the DB2 database on an AIX box,
developers have heavylly used varchar to hold chinese strings. Now we
try the OLE DB provider, ADO.NET/ODBC and ADO.NET/OLE DB provider in
SSIS ,everything works well except those strings. That's really
strange.

Well, give the recommendation a shot, otherwise I recommend support.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

[Amber]

Hi Serge Rielau
There is something more interesting, when I use the "db2set
DB2CODEPAGE=819" command on my

workstation, Quest Central for DB2 can interpret the iso 88591
strings, but the offical tool

Control Center(I use DB2 UDB 9.1) can't; when I use the "db2set
DB2CODEPAGE=" command to

unset this property, Quest Centeral just can't connect to DB2, and the
offical tool still

can't iso 88591 string, but this time it seems the offical one is a
little more clever,

because it can connect to server and do other things.