2006 Jul 24 12:43 PM
Hi,
Code Inspector show that Translate command is obsolete. please let me know the alternate command to be used for the Translate.
Thanks & Regards,
Madhuri.
2006 Jul 24 12:52 PM
Hi,
no alternative command for translate , use set language before using the translate command .
Regards
Appana
Check this :
TRANSLATE c TO UPPER/LOWER CASE: Additional Information
Variants:
TRANSLATE c TO UPPER CASE.
TRANSLATE c TO LOWER CASE.
The way in which the TRANSLATE statement works depends on the R/3 logon language. In general, users log on to the R/3 System in the same language as that in which the data they want to edit was created. Logging on in the wrong language causes loss of data, unless a conversion has been defined to deal with a different language environment.
For example, if German umlauts are processed in a Russian environment, the TRANSLATE statement returns a '|' for an 'ö' and a '¶' for a 'Ö'. Such discrepancies occur in particular:
If the wrong language environment has been set inSET LOCALE LANGUAGE
If the user edits data that was not written in the logon language (without using SET LOCALE LANGUAGE)
If, for example, the data to be converted is stored in a structure struwith the language key languand the text field text, then you can work round the problem in one of two ways:
Example
DATA: BEGIN OF stru,
langu TYPE sy-langu,
text TYPE sy-xcode,
END OF stru.
SET LOCALE LANGUAGE stru-langu.
TRANSLATE stru-text TO UPPER CASE.
SET LOCALE LANGUAGE SPACE.
This solution ensures that every conversion is made in the appropriate language. If struis an internal table, it should be sorted beforehand, to reduce the number of times the system switches between languages. Depending on the table's range, this can substantially reduce processing time, since SET LOCALE LANGUAGE has a long processing time. The runtime is similar to the runtime for SQL statements.
Example
IF stru-langu = sy-langu.
TRANSLATE stru-text TO UPPER CASE.
ELSE.
....
ENDIF.
The above solution ensures that only texts created in the logon language are edited. If you want, you can bundle all other text lines in another internal table using COLLECT and then convert them using the first solution above.
Note
It is important to reset the language explicitly using SPACE, since SET LOCALE LANGUAGE also changes the system field sy-langu. Note also that a language key may not be meaningful, or a language may not be installed correctly, or you may not be able to edit data from a specific application server. In these special circumstances, the following function modules can be used:
SCP_MIXED_LANGUAGES_1_INIT
SCP_MIXED_LANGUAGES_1_SWITCH
SCP_MIXED_LANGUAGES_1_NORMAL
SCP_MIXED_LANGUAGES_1_FINISH
Hi,
no alternative command for translate , use set language before using the translate command .
Regards
Appana
Check this :
TRANSLATE c TO UPPER/LOWER CASE: Additional Information
Variants:
TRANSLATE c TO UPPER CASE.
TRANSLATE c TO LOWER CASE.
The way in which the TRANSLATE statement works depends on the R/3 logon language. In general, users log on to the R/3 System in the same language as that in which the data they want to edit was created. Logging on in the wrong language causes loss of data, unless a conversion has been defined to deal with a different language environment.
For example, if German umlauts are processed in a Russian environment, the TRANSLATE statement returns a '|' for an 'ö' and a '¶' for a 'Ö'. Such discrepancies occur in particular:
If the wrong language environment has been set inSET LOCALE LANGUAGE
If the user edits data that was not written in the logon language (without using SET LOCALE LANGUAGE)
If, for example, the data to be converted is stored in a structure struwith the language key languand the text field text, then you can work round the problem in one of two ways:
Example
DATA: BEGIN OF stru,
langu TYPE sy-langu,
text TYPE sy-xcode,
END OF stru.
SET LOCALE LANGUAGE stru-langu.
TRANSLATE stru-text TO UPPER CASE.
SET LOCALE LANGUAGE SPACE.
This solution ensures that every conversion is made in the appropriate language. If struis an internal table, it should be sorted beforehand, to reduce the number of times the system switches between languages. Depending on the table's range, this can substantially reduce processing time, since SET LOCALE LANGUAGE has a long processing time. The runtime is similar to the runtime for SQL statements.
Example
IF stru-langu = sy-langu.
TRANSLATE stru-text TO UPPER CASE.
ELSE.
....
ENDIF.
The above solution ensures that only texts created in the logon language are edited. If you want, you can bundle all other text lines in another internal table using COLLECT and then convert them using the first solution above.
Note
It is important to reset the language explicitly using SPACE, since SET LOCALE LANGUAGE also changes the system field sy-langu. Note also that a language key may not be meaningful, or a language may not be installed correctly, or you may not be able to edit data from a specific application server. In these special circumstances, the following function modules can be used:
SCP_MIXED_LANGUAGES_1_INIT
SCP_MIXED_LANGUAGES_1_SWITCH
SCP_MIXED_LANGUAGES_1_NORMAL
SCP_MIXED_LANGUAGES_1_FINISH
2006 Jul 24 12:46 PM
U can use REPLACE.
IF u can give the details, i can be more specific.
-Aarthi.
2006 Jul 24 12:52 PM
Hi,
no alternative command for translate , use set language before using the translate command .
Regards
Appana
Check this :
TRANSLATE c TO UPPER/LOWER CASE: Additional Information
Variants:
TRANSLATE c TO UPPER CASE.
TRANSLATE c TO LOWER CASE.
The way in which the TRANSLATE statement works depends on the R/3 logon language. In general, users log on to the R/3 System in the same language as that in which the data they want to edit was created. Logging on in the wrong language causes loss of data, unless a conversion has been defined to deal with a different language environment.
For example, if German umlauts are processed in a Russian environment, the TRANSLATE statement returns a '|' for an 'ö' and a '¶' for a 'Ö'. Such discrepancies occur in particular:
If the wrong language environment has been set inSET LOCALE LANGUAGE
If the user edits data that was not written in the logon language (without using SET LOCALE LANGUAGE)
If, for example, the data to be converted is stored in a structure struwith the language key languand the text field text, then you can work round the problem in one of two ways:
Example
DATA: BEGIN OF stru,
langu TYPE sy-langu,
text TYPE sy-xcode,
END OF stru.
SET LOCALE LANGUAGE stru-langu.
TRANSLATE stru-text TO UPPER CASE.
SET LOCALE LANGUAGE SPACE.
This solution ensures that every conversion is made in the appropriate language. If struis an internal table, it should be sorted beforehand, to reduce the number of times the system switches between languages. Depending on the table's range, this can substantially reduce processing time, since SET LOCALE LANGUAGE has a long processing time. The runtime is similar to the runtime for SQL statements.
Example
IF stru-langu = sy-langu.
TRANSLATE stru-text TO UPPER CASE.
ELSE.
....
ENDIF.
The above solution ensures that only texts created in the logon language are edited. If you want, you can bundle all other text lines in another internal table using COLLECT and then convert them using the first solution above.
Note
It is important to reset the language explicitly using SPACE, since SET LOCALE LANGUAGE also changes the system field sy-langu. Note also that a language key may not be meaningful, or a language may not be installed correctly, or you may not be able to edit data from a specific application server. In these special circumstances, the following function modules can be used:
SCP_MIXED_LANGUAGES_1_INIT
SCP_MIXED_LANGUAGES_1_SWITCH
SCP_MIXED_LANGUAGES_1_NORMAL
SCP_MIXED_LANGUAGES_1_FINISH
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |