Non Alpha-Numeric Characters in Layout Names

[Robert Davis]

Are any and all characters allowed in layout names? Or are certain non-alphanumeric characters (e.g.: "re-port / name [foo_bar]") apt to cause problems and best to be avoided?

Thanks

D

[Melvin Davidson]

RE: Non Alpha-Numeric Characters in Layout Names

The valid characters for a layout are
A-Z, 0-9 and the underscore.

Basically, whatever applies for a field name applies to layouts as well

[Stan Mathews]

RE: Non Alpha-Numeric Characters in Layout Names

To "enhance" Melvin's advice, from the documentation -

Alpha Five recommends that table and field names start with a letter (A-Z or a-z) and be composed of letters, numbers (0-9), and underscore (_) characters.

Note the omission of the space character in this recommendation

[Robert Davis]

RE: Non Alpha-Numeric Characters in Layout Names

Thanks. I was unable to find this in any docs. This may explain some anomalies.

[Robert Davis]

RE: Non Alpha-Numeric Characters in Layout Names

Something else occurred to me --- Does this restriction also apply to table and set names?

[Melvin Davidson]

RE: Non Alpha-Numeric Characters in Layout Names

Yes, and you cannot use spaces in a table or set name.

[Robert Davis]

RE: Non Alpha-Numeric Characters in Layout Names

AAAAAAAAARRRRRRRRRRRRGGGGGGGGGGGGHHHHHHHHHHH !!!!!

This means much wasted work

thanks anyway

[Melvin Davidson]

RE: Non Alpha-Numeric Characters in Layout Names

Robert,

I can understand your frustration. However, for the future,
keep in mind that table and object names, while they should have logical meaning, are only a reference for the database engine.

It is quite legal to name a table or set that holds data about employees "ef23_fm". However, for readability and ease of coding, it is better to name it "employees".

When referring to fields/objects in a form, the text label
can be entirely different than the actual object name. So
if at that point, you find it necessary to make the label
"o_bla_di_68_ 24%#@ HeckleJeckle", it is perfectly legal to do so. :)

[Melvin Davidson]

RE: Non Alpha-Numeric Characters in Layout Names

FYI,

I am attaching an old version of the specs in the hopes
it will assist you with other considerations. Please note some of those specs may be superseded by the newer release of Alpha Five planned for later this month.

[CALocklin]

RE: Non Alpha-Numeric Characters in Layout Names

Actually, spaces are allowed in table and set names but I don't recommend using them. I also recommend keeping table and set names relatively short - even though long names are allowed.

Although these things are allowed, there are some situations where either one can cause "issues."

Examples:

If you code an append in xbasic and the table being appended from has blank spaces in the name, some parts of the script will have to have underscores substituted for the spaces and others will have to maintain the spaces. The tricky part is knowing where to apply each method. The easy solution - don't use blank spaces in names.

If you have a complex expression that requires the use of table and/or set names and you use long names, the expression may not be able to be completed because expressions are limited to 1024 characters. (And, yes, I have come up against this limit.)



Finally, at the risk of upsetting those who've seen this reference many times before, you might like to read my little "treatise" on A5 naming recommendations.

One thing that is mentioned in my "treatise" but not particularly emphasized is that I like to use underscores in names for other reasons as well....

1. They are more readable in the sense that it's not as obvious that you are referring to a specific entity when a form is named new invoice payments vs. new_invoice_payments. My guess is that the previous sentence was difficult to read at first but it should have been obvious what the form name was once you got to the version with the underscores.

2. Running searches on form names with underscores will be more accurate. In many cases there are buttons or comments that have the same 'name' as the form. Using the above example, a button may say "New Invoice Payments" and a text search in A5Doc will not be able to distinguish between that and a form with the same name. However, when the underscores are added to the name, the name is no longer the same.

3. You can double click on New_invoice_payments [in the A5 code editor] to select it but you have to carefully drag across 3 words to select New Invoice Payments. This may be minor when you only need to do it once but it starts to become annoying if you have to do it 50 times a day.

Cal Locklin
www.aimsdc.net

[JerryBrightbill]

RE: Non Alpha-Numeric Characters in Layout Names

Robert

To add to what has been posted, it is a very good idea to keep all field names and index names to 10 characters or less. The native dbf format has a limitation of only 10 characters for names. Alpha allows up to 24 characters. To use the longer names, Alpha saves the longer name in the data dictionary files for the table (ddm, ddx, ddd files). It then uses a truncated name in the actual table that is the first 9 characters and a number and links the 2 names. Normally, this works great and the user always sees the long name. However, if the data dictionaries become corrupted, the link may be lost. Then all references to indexes and fields fail and it is not pretty. If all names are 10 characters or less, then the names are not saved in the dictionaries and any corruption will not damage any reference.

Jerry