Kbase P79261: Error 247 because LE is a 4GL reserved keywords that means Less or Equal
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/1/2004 |
|
Status: Unverified
SYMPTOM(s):
** Unable to understand after -- "<string>". (247)
CAUSE:
Trying to use a variable called lE (LE). LE is a 4GL reserved keyword that means Less or Equal (you can use '<=' instead).
Sometimes, is doe snot make any problem, but sometimes it does, as illustrated bellow.
This sample works fine:DEF VAR lA AS LOG.
DEF VAR lB AS LOG.
DEF VAR lC AS LOG.
DEF VAR lD AS LOG.
DEF VAR lE AS LOG.
ASSIGN
lA = FALSE
lB = FALSE
lC = FALSE
lD = FALSE.
lE = FALSE.
But this one does not[...]
ASSIGN
lA = FALSE
lB = FALSE
lC = FALSE
lD = FALSE
lE = FALSE.
First, keep in mind that using 4GL reserved keyword for your own ressource (variable, buffer, temp-table, function/procedure names...) is not recommended. One good reason is that since version 9, we provide a colored 4GL editor that automatically converts 4GL reserved keywords in upper case and display them in blue when you type them (you can still refine in lower case but they still show in blue). This makes the reading of 4GL code really more comfortable and convivial, but typing "LE" or "CODE" for variable name will inevitably convert to upper case.
The reason that 2nd sample fails is that with you can do:
a = b = c.
This means that a = YES if b is equal to c and NO otherwise.
Note this works with any data type (not only logicals)
Now you can also type "a = b LE c" because LE (Less or Equal, can also use '
Now pay attention to:[...]
lD = FALSE
lE = FALSE
[...]
The compiler ignores carriage returns so it takes it as:
lD = FALSE LE = FALSE
1) there is a valid logical expression on the left of LE (FALSE)
2) the datatype of this expression is of same data type (logical) as the variable lD to assign
3) But the 2nd expression at the right of LE makes problem with the second equal sign...
Indeed, the compiler expects something like:
lD = FALSE LE <logical expression>
For instance "lD = FALSE LE FALSE" would be perfectly valid.
Now, sure, if you split the multiple assign with a full stop, then Progress understands that lE cannot be an operator because it has nothing on its left, so it takes it as a variable name.
The compiler must first assume that reserved keywords are indeed 4GL reserved keywords before finding out that the word usage is not compatible with the grammar (here, something on the left of LE operator, or not thanks to previous full stop) so it has to be taken as a simple variable name.
Trying to implement an exception in the 4GL compiler to handle this case so it would guess that taking LE as a variable name even when there is a valid expression on its left would be risky.
FIX:
The best option is to change the name of this 'lE' variable.