Unable to resolve WVARCHAR to DB2 table
Moderators: chulett, rschirm, roy
Re: Unable to resolve WVARCHAR to DB2 table
Hi tbtcust
what is the column length in DataStage and in DB2?
I suppose your database hast been created with UTF-8 and this means that a single character can be stored in 1,2,3 or even 4 bytes.
Be aware that DB2 length specifications at the moment are in bytes (and not in characters). This can lead to your mentioned warnings.
what is the column length in DataStage and in DB2?
I suppose your database hast been created with UTF-8 and this means that a single character can be stored in 1,2,3 or even 4 bytes.
Be aware that DB2 length specifications at the moment are in bytes (and not in characters). This can lead to your mentioned warnings.
regards
Michael
Michael
Hi tbtcust
For example if you have a length of 10 in DataStage - try using 40 in DB2 ( as a single character could be stored in up to 4 bytes using UTF-8 ).
OK - but is the specified length in DataStage the same as in DB2?Some columns are as small as 1 and as large as 80. The database code set is UTF-8.
For example if you have a length of 10 in DataStage - try using 40 in DB2 ( as a single character could be stored in up to 4 bytes using UTF-8 ).
regards
Michael
Michael
So, are you having any of the issues it is warning you of - data loss, corruption, data truncation or unexpected errors? It's just a warning after all, so could always be demoted via a message handler if everything seems to be working fine.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Hi tbtcust,
reading from a file into a DB2 UTF-8 database should be possible without warnings.
Having UTF-8 for the database and as NLS in the DataStage job
you could use the DB2CODEPAGE set to 1208. Make this a job parameter and do not user the extended unicode for the column and it will work without warnings.
At least it does in my environment.
Otherwise - as suggested above - demote it to informational in the director
reading from a file into a DB2 UTF-8 database should be possible without warnings.
Having UTF-8 for the database and as NLS in the DataStage job
you could use the DB2CODEPAGE set to 1208. Make this a job parameter and do not user the extended unicode for the column and it will work without warnings.
At least it does in my environment.
Otherwise - as suggested above - demote it to informational in the director
regards
Michael
Michael
Hello ray, I do have a reject link. Records never seem to land there. High-level, as a test I have the commit set to 2000, load three records. The first and third are fine the second has an invalid date. DataStage throws a warned on the second record, did not load that record, nothing landed in the reject file, the failure did not cause the previously inserted record to roll back, and lastly loaded the third record.
Hello MT, I'm not familiar with 1208 so I looked it up. I have done what you mentioned. The warnings did go away. This DB instance will store multi-languages. With this solution it seems we loss that multi-language support. True?
Also, as a test I left everything as-is and removed extended unicode. and there are no warnings as well.
Hello MT, I'm not familiar with 1208 so I looked it up. I have done what you mentioned. The warnings did go away. This DB instance will store multi-languages. With this solution it seems we loss that multi-language support. True?
Also, as a test I left everything as-is and removed extended unicode. and there are no warnings as well.
Apologies MT, having a Homer moment.
I asked you "With this solution it seems we loss that multi-language support. True?"
My original tests was in English. I reran both test using Spanish language, which included inserts and export from the DB. The results were perfect.
So it seems the solution is to always removed from extended "Unicode" and DataStage will take care of the rest.
I asked you "With this solution it seems we loss that multi-language support. True?"
My original tests was in English. I reran both test using Spanish language, which included inserts and export from the DB. The results were perfect.
So it seems the solution is to always removed from extended "Unicode" and DataStage will take care of the rest.
Hi tbtcust
1208 is UTF-8 and this environment variable sets it for DB2.
I would not say that it is always the solution, but in many cases it is.
We have other jobs working well with Unicode extended attribute and it seems it "depends" on combinations used.
Many things can only be found out by trial & error. To be honest - I hate those
1208 is UTF-8 and this environment variable sets it for DB2.
I would not say that it is always the solution, but in many cases it is.
We have other jobs working well with Unicode extended attribute and it seems it "depends" on combinations used.
Many things can only be found out by trial & error. To be honest - I hate those
regards
Michael
Michael