[resolved] changing encoding type output on a column by column basis

[Anonymous]

In a tMap, when defining output, some columns need to be output to standard ISO-8859-15 (single byte latin), and other columns need to be cast into utf8 (double byte).
How do you do this in a tMap / tJavaFlex?
Dave

[Anonymous · Accepted solution]

David,
Input and Output components have Encoding property in the Basic or Advanced properties. You can just choose UTF-8 instead of ISO-885915 for all components in your Job Designs.
If you need some in an enconding and some other into another, maybe it's probably easier to have two separate subJob, one on UTF-8 the other one on ISO-885915 on the components.
Another way is to call user_routines which have some method to encode the data on the fly into a tMap or other components.

[Anonymous]

David,
Input and Output components have Encoding property in the Basic or Advanced properties. You can just choose UTF-8 instead of ISO-885915 for all components in your Job Designs.
If you need some in an enconding and some other into another, maybe it's probably easier to have two separate subJob, one on UTF-8 the other one on ISO-885915 on the components.
Another way is to call user_routines which have some method to encode the data on the fly into a tMap or other components.

? Is it safe to say that, for a tOracleInput set to utf-8, which has columns of:
col1 varchar2(10)
col2 nvarchar2(10)
col3 varchar2(10)
I can just map to a tOracleOutput set to utf-8 (assume col1=>col1 , col2=>col2, col3 =>col3)
col1 varchar2(10)
col2 nvarchar2(10)
col3 nvarchar2(10)
So, in other words, I do not need to do any explicit casts in the tmap? (note col3)
Dave

[Anonymous]

David,
From my point of view it's safe.
Normally, you don't need to cast (for it you mean encode) at all the object.
Once your data is read with the right encoding from the source and become an Object (String, Float, ...) and then is written using the right encoding too; you don't care about the Life of the object during the date flow.
For example you can have a source in ISO-885915 and a target in UTF-16, you just need to indicate the right encoding for each one; but nothing to do in the middle components like tMap, etc...
Best regards;

[Anonymous]

David,
From my point of view it's safe.
Normally, you don't need to cast (for it you mean encode) at all the object.
Once your data is read with the right encoding from the source and become an Object (String, Float, ...) and then is written using the right encoding too; you don't care about the Life of the object during the date flow.
For example you can have a source in ISO-885915 and a target in UTF-16, you just need to indicate the right encoding for each one; but nothing to do in the middle components like tMap, etc...
Best regards;

That's fantastic. When coding in SSIS (Miscrosoft ETL), I always had to explicitly cast at the column level, when moving data from single byte to unicode.
Example source.col1 as varchar2(10), and destination.col1 as nvarchar2(10). In SSIS, would have to do a cast as: destination.col1 = (wst)Source.col1 within the data pipeline (wst is explicit cast to unicode), or I would get an error.
That's great in Talend, to not have to worry about that.
Dave