Is there any routine or function module to have all special country characters translated into standard characters, let's say to A-Z a-z and 0-9 ?
I mean all special characters codes because I get short dump that convertion fails. It is special characters from polish language, turkish and many more..
NAVEEN KUMAR GUDURI replied
the function module SCP_REPLACE_STRANGE_CHARS will do the job
When you test the function module in SE37, make sure that you put a check in the checkbox Uppercase/Lowercase.
Checks whether TRANSLATE .. TO UPPER/LOWER CASE statements are working in the correct language environment.
TRANSLATE .. TO UPPER/LOWER CASE statements are displayed that work on table fields without a preceding SET LOCALE LANGUAGE statement.
There are two cases:
1. The table containing the field to which the TRANSLATE statement applies contains a language field.
In this case, the data processed comes from a table containing a language field (regardless of whether the field occurs in the key). You can probably set the correct language environment before the TRANSLATE statement is executed.
2. The table does not contain a language field.
If the current table does not contain a language field, the error is harder to correct. You can either determine the language using other means, or add a language field to the table and fill it with the correct values.
The TRANSLATE statement depends on the current language environment, which itself depends on the language in which the data was entered.
Incorrect settings for the language environment can cause loss of data if, for example, you use the TRANSLATE statement to generate matchcodes.
Examples of problems in the TRANSLATE statement:
What is the UPPER CASE of 'ä'?
In German - 'Ä'.
In French - 'A'.
In English, however, it would depend on the implementation, since 'ä' is not recognized at all.
In Japanese, serious errors occur. The byte with the bit combination that looks like 'ä' is in fact the first half of the double-byte representation of many different kanji.
If your try to process German data in a Russian environment, the result is variable: 'ä' and 'Ä' are processed correctly. However, 'ö' becomes '¦', and 'Ö' is converted to '¶'. The capital 'Ö' has a bit combination that stands for a small 'sch' in the Russian character set.
When does the problem occur?
1. Problems of this nature can occur if the wrong language environment has been set up using SET LOCALE. However, this is very rarely the case, and the system does not check for it.
2. The problem can also occur if you do not use SET LOCALE at all and then process data that has a language other than the logon language, and this is a far more common cause. Since language key fields are not automatically filled, you cannot easily tell from an ABAP program whether it processes texts in foreign languages. (For comparison, think of clients, where you can recognize the source of data from the addition "CLIENT SPECIFIED".) Since this is not easily recognizable for languages, the extended program check lists critical points instead.You must either correct these or flag them as OK using a special pseudocomment.
Check whether you have set the language environment correctly before the TRANSLATE statement, and if necessary, add a SET LOCALE LANGUAGE statement (as described in the examples below).
Then, add the pseudocomment
after the TRANSLATE statement (but on the same line) to indicate that the programming is correct.
The extended program check automatically takes into account SET LOCALE LANGUAGE statements and 'SCP_MIXED_LANGUAGES_1_SWITCH' calls if they occur shortly before a TRANSLATE statement, but the pseudocomment is a safer way to ensure that the point in the program will not be listed in the check results.
THere is a further pseudocomment
to indicate that the TRANSLATE statement is allowed because the data only uses characters from the 'syntactical character set'.
There are several ways of solving the problems:
The following examples suppose a table with a text field and a language key:
DATA: BEGIN OF data OCCURS 0,
langu LIKE sy-langu,
txt(20) TYPE CHAR,
END OF data.
Old TRANSLATE data-txt TO UPPER CASE.
New proposal SET LOCALE LANGUAGE data-langu.
TRANSLATE data-txt TO UPPER CASE.
SET LOCALE LANGUAGE SPACE.
This is a correct solution, and simple because it does not require wide-ranging changes to the program. Each TRANSLATE TO UPPER CASE statement occurs in the correct environment.
The disadvantage is that there may be a large number of locale switches, and the SET LOCALE command takes up runtime. This solution also fails to account for two conditions, although these should not occur very often:
The language in data-txt may be invalid. This would cause a runtime error.
The program may not be running in the logon language. The SET LOCALE LANGUAGE SPACE statement always resets the locale to the logon language.
Solution 2: With sort:
If the data can be sorted without a problem because, for example, they are in an internal table that is not too large, it may be quicker to sort the data first. This minimizes the number of switches required:
SORT data BY langu.
LOOP AT data.
IF data-langu >< SY-LANGU.
SET LOCALE LANGUAGE data-langu.
TRANSLATE data-txt TO UPPER CASE.
SET LOCALE LANGUAGE SPACE.
SORT data BY keyfield1 keyfield2.
Solution 3: Several passes:
This solution requires the most programming, and is only worthwhile if you need to process large amounts of data that could be processed sequentially, but would be time consuming to sort, and are not already sorted more or less by language.
In the first pass, you only convert the texts that are already in the logon language. Additionally, you use COLLECT to note all of the other languages that occur in an internal table.
You can then loop through the internal table, switch to the next language, and run through the entire dataset again.
An example of this would be too long for this documentation. The "2nd procedure" in RSCP0104 is a test of this procedure.
Solution 4: Only process the logon language:
IF data-langu = sy-langu.
TRANSLATE data-txt TO UPPER CASE. "#EC TRANSLANG
" Something important missing ?
SET LOCALE also changes the SY-LANGU field. Before processing more than TRANSLATE TO UPPER CASE and small, easy-to-understand actions, you should switch back to the logon language immediately, especially before calling new procedures.
Depending on the data, it is possible that nosensical contents can appear for a given language key, that you are using a language that cannot be processed on a particular application server, or that a language is not properly installed.
To ensure that application programs do not have to deal with these cases, there are four function modules that you can use:
Called at the start of processing
Switches to a paticular language
Allows you to switch back temporarily to the language that was active when you called SCP_MIXED_LANGUAGES_1_INIT
Called at the end of processing.
Like many function modules, these have few obligatory parameters for normal use, but do have a range of optional additional parameters for special cases.
If you do not catch any exceptions, you can expect that the function module will either run successfully or that the program will terminate with a short dump. Using these functions, solution 1 looks like this: Lösung 1 folgendermaßen aus:
CALL FUNCTION 'SCP_MIXED_LANGUAGES_1_INIT'.
LOOP AT data. " Or SELECT, or...
CALL FUNCTION 'SCP_MIXED_LANGUAGES_1_SWITCH'
EXPORTING need_lang = data-langu.
TRANSLATE data-txt TO UPPER CASE. "old code
CALL FUNCTION 'SCP_MIXED_LANGUAGES_1_NORMAL'.
CALL FUNCTION 'SCP_MIXED_LANGUAGES_1_FINISH'
i think u will find some answer in it
if it is useful reward some points