RPG provides a few ways to replace characters in a string, such as the %XLATE BIF. SQL also has interesting—and, more importantly, easy to use—functions to transform strings, changing the case of its characters or replacing them altogether.
The previous article in this series discussed a set of scalar functions you can use to convert data to its representation in string format. Once this data is in string format, you can use it with text information from your files in order to create descriptions or other texts, which you can use in reports. However, these texts might require a different type of conversion; their case might not be the most adequate, or you might want to replace a character somewhere in the middle of the string. I could argue that his is also a conversion, albeit a different one.
Let's start with the functions that convert all characters of a string to lowercase. LCASE and LOWER both take a string as input and return a string in which all the characters have been converted to lowercase characters, based on the CCSID of the argument. Only Single Byte Character Set (SBCS), Unicode graphic characters are converted. The characters A-Z are converted to a-z, and characters with diacritical marks, such as "Á" and "Ö," are converted to their lowercase equivalent. For example, the following statement returns 'this is a test' and 'isto é um teste'.
SELECT LCASE('THIS IS A TEST')
, LOWER('ISTO É UM TESTE')
Note that the "É" character was converted to its lowercase equivalent, "é." The UCASE and UPPER functions do the exact opposite:
SELECT UCASE('this is another test')
, UPPER('este é outro teste')
Executing this statement would result in 'THIS IS ANOTHER TEST' and 'ESTE É OUTRO TESTE'. These functions provide the same functionality RPG's %XLATE does, but you don't have to worry about input and output translation tables; the database engine does that for you.
However, there are situations in which you use %XLATE to actually translate or replace characters in a string. SQL also provides a function for that: TRANSLATE. You can say that TRANSLATE is SQL's equivalent to the %XLATE BIF: it takes four parameters: the string to convert; the output translation table; the input translation table; and the character used for padding, which will only be used if the output translation table is shorter than the input translation table. Note that the input and output translation tables are reversed, when compared to %XLATE. This BIF also lacks the padding feature. I know this sounds confusing, so let's look at a couple of examples. First, I'll do a simple character replacement:
SELECT TRANSLATE('Test string', 'B', 'T')
This statement returns 'Best string'. It used the input translation table ('T') over the string to convert ('Test string') to find the characters to translate—in this case, it found only one; then it looked in the output translation table ('B') for the replacement character and performed the "translation" operation, thus transforming 'Test string' into 'Best string'. Let's see another simple example, with longer translation tables:
SELECT TRANSLATE('Test string', 'Boll', 'Ting')
This statement returns 'Best stroll', replacing the 'T' by 'B', the 'i' by 'o', the 'n' by 'l' and the 'g' for another 'l'. By now, you should have grasped the way the translation tables are used, so let's complicate things a bit by introducing the fourth parameter (the padding character) in the next example:
SELECT TRANSLATE('Test string', 'Boll', 'Tings', '$')
Notice that the output translation table is shorter than the input translation table. In this situation, if a character from the input translation table is found in the string to convert, the padding character is used to complete the translation. With this piece of information, try to figure out what the output string is going to be…. Don't look yet, but it's written below!
'Be$t $roll'—that's the output. Because there's no match for the 's' in the output translation table, all occurrences of the 's' character are replaced with the padding character '$'.
It might not be clear at this time why I'm explaining functions that provide something that the %XLATE BIF already provides. You'll see later in this series, when I discuss how to embed SQL in your RPG programs, how these (and other functions I'll explain in the meantime) can be used instead of RPG's BIFs, providing enhanced functionality with a fraction of the development and maintenance cost.
Speak your mind in the comments section below. I'd like to hear from you