By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,610 Members | 2,310 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,610 IT Pros & Developers. It's quick & easy.

IBM OLE DB Provider for DB2 Codepage error.

P: n/a
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.

Jan 26 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Are there any IBM Guys,^_^

Jan 29 '07 #2

P: n/a
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
Jan 29 '07 #3

P: n/a
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.

Jan 30 '07 #4

P: n/a
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
Jan 30 '07 #5

P: n/a
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.

Jan 30 '07 #6

P: n/a
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
Jan 30 '07 #7

P: n/a
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.

Feb 1 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.