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;
Customer Group
FirstName String(100)
LastName String(100)
End
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;
CUSTOMER Group
FIRSTNAME String(100)
LASTNAME String(100)
End
You can set a specific NAME attribute, with a specific case to each field.
Customer Group,Name('Customer')
FirstName String(100),name('FirstName')
LastName String(100),name('LastName')
End
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.
So where you could have used the NAME property to improve the readability of a column name,
I’m not sure what you mean by “readability” here. Are you suggesting your label is not readable? Or that you routinely have a different label to name (other than case?)
As an example, let’s say you have a record declaration of a SQL table in your DCT, something like this:
Client FILE,DRIVER('MSSQL'),NAME('dbo.CLIENT'),PRE(CLI),BINDABLE,THREAD
Client_PK KEY(CLI:GUID),PRIMARY
Client_SK KEY(CLI:ClientCode)
Record RECORD,PRE()
GUID CSTRING(17),NAME('GUID')
ClientCode CSTRING(21),NAME('C_CDE')
Name CSTRING(101),NAME('C_NME')
PhysicalAddress CSTRING(501),NAME('C_PADDR')
BillingAddress CSTRING(501) ,NAME('C_BADDR')
END
END
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.