Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook



The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic

Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.

If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.

Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.

Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Ten characters Field Name Rule

  • Filter
  • Time
  • Show
Clear All
new posts

  • Ten characters Field Name Rule


    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?


  • #2
    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?
    There can be only one.


    • #3
      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.



      • #4
        Re: Ten characters Field Name Rule


        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?



        • #5
          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.
          There can be only one.


          • #6
            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. :-)



            • #7
              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.


              • #8
                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.



                • #9
                  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.
                  It is only when we forget all our learning that we begin to know.
                  It's not what you look at that matters, it's what you see.
                  Henry David Thoreau


                  • #10
                    Re: Ten characters Field Name Rule

                    Originally posted by Stan Mathews View Post
                    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."


                    • #11
                      Re: Ten characters Field Name Rule


                      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.



                      • #12
                        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.


                        • #13
                          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., 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


                          • #14
                            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.

                            Ira J. Perlow
                            Computer Systems Design

                            CSDA A5 Products
                            New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
                            CSDA Barcode Functions

                            CSDA Code Utility
                            CSDA Screen Capture


                            • #15
                              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.
                              Dave Mason
                              [email protected]
                              Skype is dave.mason46