This question comes up a lot, so I’d like to add an FAQ of sorts on it here.
Clarion is a case insensitive language. But many other languages (and data formats) are case sensitive. This can lead to complications when interacting with those formats and languages.
Take this declaration;
The word in column 1 is the LABEL, not the NAME of the field.
Since Clarion is case insensitive all LABELS are automatically turned into UPPER case by the compiler.
In the absence of a NAME attribute, the LABEL (which is uppercase) is used as the name.
So this declaration is seen by the compiler as this;
You can set a specific NAME attribute, with a specific case to each field.
Any code (think jFiles & xFiles) which takes the structure at runtime is going to need the Name attribute if you want to make a mixed-case output. In some cases (think jFiles and xFiles again) a case insensitive match can be done for Input - using the appropriate TagCase property.
I think the only unfortunate aspect of the NAME property, is that on an SQL table, this also refers to the actual column name in the SQL table (or external name as the help file calls it). So where you could have used the NAME property to improve the readability of a column name, it can also force you to reduce readability when you need to use the actual underlying column name - and in this case there is no alternative property to use for a “friendly” column name, except maybe by adding a column property in the DCT.
As an example, let’s say you have a record declaration of a SQL table in your DCT, something like this:
BillingAddress CSTRING(501) ,NAME('C_BADDR')
The columns here (possibly due to legacy reasons) don’t have “friendly” external names. Although the DCT name is “friendly”, the use of the NAME property will actually then reduce readability of the column name. For example in jFiles and xFiles then, one can’t use the reverse option to use the DCT name rather than the external name - because the value in the NAME property will get preference.
Yes, in this case you have unfriendly External Names. The Labels have been made friendly at some point, but that’s purely for the sake of the programmer, those names are not exposed to the outside world.
For example in jFiles and xFiles then, one can’t use the reverse option to use the DCT [label] rather than the external name - because the value in the NAME property will get preference.
Correct. jFiles / cFiles work on the Name, not the Label. That’s because it reflects (looks into) the structures at run-time, not compile-time and the Label is a compile time thing, the Name is the runtime thing.
The root of your problem of course (perhaps for legacy reasons) are the unfriendly names in the database. Which I suppose if a good example of why getting names in the database right is important.