Ten characters Field Name Rule

[chematercero]

Hi,

I was reading on some thread that is better to adhere to this rule, why?

Also, I was noticing you can use cammel notation (upper and low case) for table names. Is it possible to overwrite this?

Regards,

[Stan Mathews]

Re: Ten characters Field Name Rule

Longer fieldnames are stored in the data dictionaries. Should they become corrupted or overwritten, the longer names are lost and references to them are invalid.

Is it possible to overwrite this?

No.

[Bill Parker]

Re: Ten characters Field Name Rule

Some are adamant about limiting fieldnames to 10 characters. I go the other way, and have not had a case of truncated fieldnames in 15 years. I am likely to make more mistakes when coding with a fieldname of
recstmtdt vs. Reconciledstatementdate

OTOH, I do get index names truncatred to 10 characters. For that I use Cal Locklin's index rebuild utility.

Bill.

[chematercero]

Re: Ten characters Field Name Rule

Fine.

Good to have opinion on both sides.

If names no longer than 10 char is considerer a good practice, now my question is: is there a way to enforce it?

Regards,

[Stan Mathews]

Re: Ten characters Field Name Rule

is there a way to enforce it

Enforce it where? The developer is the one in control. When you get to ten characters, stop. The end user does not name tables or indexes.

[Bill Parker]

Re: Ten characters Field Name Rule

If you are using 10 character field names that are shortened versions of longer names, you can store in field rules tha default "long" name to display when displaying forms and browses.

<shameless plug> In that case, it may also be useful to look at my A5Doc utility that Alpha sells in their store. It is available for trial from my website. It will print table structures with the real field name plus the default name and/or field description you put in field rules, to help you keep track of what those 10 character field names really mean. :-)

Bill.

[JohnZaleski]

Re: Ten characters Field Name Rule

Another reason to stick to 10 or less characters is if you use 3rd party software with an ODBC connection to Alpha data.The field names will appear truncated when using Crystal Reports for instance.

[Bill Parker]

Re: Ten characters Field Name Rule

Continuing my devil's advocate role here, I send a dbf with long names to an exteranl routine that does some processing and sends back a 2nd modified file.

1. In the external process I use the truncated names, which are really no worse than "shortened" names.

2. The returned dbf is appended to a local table using the truncated names -> to my long names. I could have easily built a dictionary for the returned dbf so it had long names in Alpha, but since it is only used in the append I did not bother.

3. The SQL databases that we are likely to work more with in the future are fine with long names. Quick export to Excel sends long names as column names.

4. Since I personally have not had technical problems with them, I find that long names reduce my aggravation/confusion level. But I am also fine with (and sympathize with) anyone that wants to live with short names.

Bill.

[MikeC]

Re: Ten characters Field Name Rule

:D Bill,

anyone that wants to live with short names.

Wish it was a choice I could make lightly---truncation happened to me twice early on....after the 20 plus hours of getting my applications back to where they were prior I just refuse to even consider using long names on what many imply is a slim chance of it ever happening. What is fairly "scarey" for me now is having to work with Quickbooks' names within passive-linked tables which many are over 30 characters long.

[chematercero]

Re: Ten characters Field Name Rule

Enforce it where? The developer is the one in control. When you get to ten characters, stop.

You mean I need to be counting each letter to see if the fields exceeds the 10 characters?

This is what I mean by enforce, "have AF set to not allow more than 10 chars, if you want of course."

[chematercero]

Re: Ten characters Field Name Rule

Hi,

I have some Active Link Tables, all of them containing fields with more than 10 character, so as you say before they will be stored in a data dictionary.

Will they also be in risk in case the data dictionary gets corrupted?

I also see that some other objects are stored in the data dictionary, will they also be lost in case of such corruption?

Seems be it is not a good idea to work with A5, one corrupted data dictionary and you are lost???

How is that all of you have survived to this fragile product?

I am not saying it is, I am saying it is the picture I am getting from your opinions.

Regards,

[Riverguy]

Re: Ten characters Field Name Rule

two thoughts: 1. If A5 suggests it, better stick with the program. 2. It's always to better to be concentrated. I have one field, that I need to change, that has 12chr and I recently had to copy and paste it 40 or so times. If I had to type that manually, I would have, but it really makes you appreciate 2chr fieldnames.

[Raymond Lyons]

Re: Ten characters Field Name Rule

I'm with Bill Parker on this issue. I have probably been doing this stuff for at least 15 years with at least a dozen different, complex applications. Yes, in the early days I experienced a couple of cases of field name truncation but they always were a result my doing something I was learning the hard way not to do, not to mention learning to ALWAYS having at least daily backups of all the files in the DB. In the early days I too toyed with keeping field names to no more than 10 characters, but for the reasons Bill stated I quickly decided it made no sense for me. Anyway, once I learned what causes the truncation and how to easily deal with it if happens again, as near as I can recall I have never experienced truncation or any data dictionary corruption of any kind in the last 10 years. Nothing is 100% sure except death, but to make this a big issue with Alpha Five strikes me as just a bit crazy.

Another example of this kind of thing is the old, almost universal advise from people here not to use numeric fields for ID fields, especially autoincrement. Well, for years I have used both in different applications just to see what the big deal is and came to the conclusion that in almost all cases there is no good reason not to us numerics and plenty of reason to use them. And now if you'll search most recent wisdom on that topic on this forum (e.g., http://msgboard.alphasoftware.com/al...ad.php?t=77116 you will find the tide has turned (or is turning) to preferring numerics!! Anytime you see some supposed expert say something like "Never do or use X" or "Always use UDF's, never scripts of any kind" I advise taking it with a grain of salt. They can be interesting perspectives, but come on, as general advice to all A5 developers it is just a bit over the proverbial top. Old timers used to say "there are many ways to skin a cat, not just one," and to me there is a time and a place for all tools we have available to us in Alpha Five--and yes I have learned to use plenty of UDF's in my old age, but if I go off that deep end or some other deep end, I think I should be worried about something.

Just a few opinions, and other people I deeply respect will surely disagree.

Raymond Lyons

[csda1]

Re: Ten characters Field Name Rule

My 2 cents:

I tend to subscribe to the 10 character limit as well.

Reasons to use 10 character field and index name limits (for DBF files)

• Compatibility with other Dbase compatible programs - # 1 reason
• Shorter names means more space in places where the length of expression fields are limited
• Dictionary corruptions will never corrupt names (Of course, backup, Backup, BACKUP would prevent this)
• Faster typing of names during development
• Some people tend to over name their fields, e.g. HomeResidence_Phone, as opposed to Phone or Home_Phone

Reasons to use longer names

• Can be clearer as to purpose of the field

Reasons to use really short names

• Squeezing a lot of fields into an expression, e.g. in a field rule (kind-of stupid, use a function if needed)
• To confuse others (and you 6 months down the road!) as to what is being done.

So in recap, IMHO

• Definitely use at least up to 10 characters to clearly identify the field as best as possible, e.g. HOME_PHONE
• Do not make field names overly short like HMPH on PH
• If you exceed 10 characters on 1 field, you might as well exceed on any of them. Keep the length less than or equal to 23, as occasionally there are issues with length of 24 (maybe due to alias names?)

And of course, backup, Backup, BACKUP.

[DaveM]

Re: Ten characters Field Name Rule

My extra 2 cents. Some already said.

I have worked for a company that adhered to 2 letter max table names and max 5 letters in the field names. Easy if documented properly, but can be tough to remember.

The reasoning was that all codes would be shorter and the tables did not lend themselves to easy identification. OK?.?

Some places where code(like if() is used) short table and field names are very handy.

i have had the truncation problem. yes a backup was availabel. It was a bit off the date, so there was still work to catch it up. No, i do not want that again. 10 is what all fields are being maxed at. 8 is what all my files are being maxed at.

I can think of no reason to use more than 10 for a field and no reason past 8 on a file name. No, I do not need to know your reasons. They can be changed.

If you have 300 tables in an app, make a simple text file with a list of your tables and what they are for. Simpler make a table with that info so you can search it.

same as above for field names.

It is not going to affect me which ever way you do yours, but it might affect me.