I'm a newbie in Informatica Powercenter and i'm trying to have my first step in this technology.
My first practice is to convert EDCDIC to UTF-8 using powercenter.
Is this possible to do that ?
If possible, then how can I do that ?. (I have referred to this, but It doesn't help)
Is there anything that i need to pay attention to when doing that ?
Sure, you can do that. You have to just set the codepages properly in source and target definition.
Go to the advanced properties of your source definition and set the codepage to one of the EBCDIC codepages as appropriate for you.
Similarly in target definition set the codepage to UTF-8.
Also, the Informatica integration service should be configured in Unicode.
Related
While writing records in a flat file using Informatica ETL job, greek characters are coming as boxes.We can see original characters in the database.In session level, we are using UTF-8 encoding.We have a multi language application and need to process Chinese, Russian, Greek,Polish,Japanese etc. characters.Please suggest.
try to change your page encoding. I also faced this kind of issue. We are using ANSII encoding, hence we created separate integration service with different encoding and file ran successfully.
There is an easy option. In session properties, select target flat file then click set file propeties. In that you can change the code-page. There you can choose UTF-8. By default it is in ANSII, that's why you are facing this issue.
One of the 'features' of the SAS Stored Process server is that the locale setting can change according to the context of the client. In my case, the session may be en_gb or en_us depending on whether the same request was sent by Excel or Chrome.
This can cause different results for the same report, eg when using ANYDTDTE. style informats. The quick fix is to explicitly set options locale=xxx;, but in order to gauge the significance of this it would be good to understand:
What are the main (non-cosmetic) ways in which the same program can give different results according to the session locale?
The major ways that locale affects a program are in the character set/encoding and the date/time defaults.
Character set (or encoding) is determined in part by the locale, and can make a huge difference if one locale is something like en-us and one is utf8, for example. Not only will SAS often end up defaulting to the session encoding for reading in files (if they are not specified explicitly either in the program or the file's header), but how SAS can deal with characters once read into a SAS dataset changes. DBCS encodings will have two bytes storage per character, not one, and if the locale is en-us and you expect utf8 you may not be able to handle some characters that do not transcode between the two.
Date defaults are also highly relevant. en-gb likely assumes 10/8/2015 is August 10, 2015, while en-us assumes it is October 8, 2015. This is a good reason not to use anydtdte. when you can avoid it, of course. You can avoid issues with this by explicitly setting the DATESTYLE system option. You may also have some differences in default output formats, such as the separator in ddmmyy10. or similar.
To see the differences that are possible due to locale, see the documentation for the LOCALE system option. This mentions four settings:
DATESTYLE
DFLANG (similar to DATESTYLE, affects how dates are read)
ENCODING
PAPERSIZE
Also, TRANTAB is set as part of setting ENCODING.
I have to deal with importing CSV files. The legacy solution uses MFC and ADO text driver to manage this. I know that you can specify the TextDelimiter-option within the corresponding Schema.ini file.
The problem is, that it is impossible for some input files to specify a character that isn't used within that file!
All our files are CP1252 encoded - we cannot deal with other encodings, so a "☃" (SNOWMAN, U+2603) or stuff like that provide no solution.
If I omit a character, ADO seems to fall back to the default character (doublequotes):
[Import.txt]
ColNameHeader=False
Format=Delimited(;)
TextDelimiter= //← omit character doesn't work!
col1=...
I also cannot define a sequence of characters, which would reduce the risk of mismatches to an acceptable value:
[Import.txt]
ColNameHeader=False
Format=Delimited(;)
TextDelimiter=##+# // produces error when opening the ADO connection!
So my question is: Is it possible to completly disable this feature? I just do not want any automatic text delimiting!
The code is implemented in C++ based upon MFC and ADO - so no ADO.NET solutions will help me.
This should do it:
TextDelimiter=none
I'm developing an application in MinGW/C++ that uses Windows' common dialogs. The need has arisen to collect a file name that might have non-ASCII characters in it. Is there a flag or another option for retrieving a file name in Unicode, or preferably UTF-8?
Call GetOpenFileNameW. You can do this without converting your entire app to Unicode which may be the most expedient solution.
Windows API comes in 2 flavours, ANSI and Unicode. The former has functions with an A suffix. The latter have a W suffix. You are currently using the former.
i use ATL macros like A2T and A2CW.
on the devel-computer everyhting works fine. when i use the application (visual studio 2008 pro) on another computer - the output of the ATL-macro-conversion is not readable.
i hope someone can help me to solve this problem. my application is finished - only the ATL conversion macros are the problem atm.
thanks in advance
The A2X macros use the current codepage to convert the strings. If you have literal strings (or some data you are distributing with the application) that you are converting, that were created with the codepage of the dev. computer in mind, and the other computer has a different codepage set, they will end up as gibberish. You can use APIs to explicitly specify the codepage you're converting from if this is the case. A2X macros should really only be used for content than comes as input from the user, where the codepage may vary, not for data where the codepage is known ahead of time.