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

Announcement

Collapse

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

Index Names "colliding" in .dbf Sets (internal set index naming resolution)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Index Names "colliding" in .dbf Sets (internal set index naming resolution)

    Question: If you have a set composed of several .dbf tables, is it possible that "internal set index naming resolution" could become an issue?
    Explanation:
    Two tables in a set contain identical named fields (very common)....
    Thus, both of these tables may have uniquely named indexes (when assigned by developer) at the table level, but are now common at the set level.
    Since you can end up with two "linked tables" (a set) sharing identically named fields and associated index names... Could this be an issue?

    I would think this could definitely be an issue, particularly in a scenario such as this: The designation of topparent.Index_Set() on forms built on sets!

    Ultimately, what I'm questioning here is: Is it necessary (or even prudent) the make sure all (user assigned) index names are different at the set level (in addition to the table level?) ~ This is a difficult proposition, because you never know for sure how you may end relating sets in tables as a "application" grows.

    I've begun using the following schema for indexes: Field CUSTOMERID gets assigned an index of Cstmrd__
    I'm wondering if it would be a better to add a letter (representing the table's name) to try to keep the indexes unique at the set level: The index above, Cstmrd__ would become Cstmrd_c_. (where the "c" is added to designate this index has been exclusively assigned to a field in the CUSTOMERS table)

    The other question is: For "performance considerations", exactly when is it necessary to even designate an index. I've read that a5 (in many instances) creates indexes automatically (regardless of what user has created beforehand). ~ My assumption is: "You should create an index anytime you know a5 may be using the field for sorting or searching." (But I've never read that anywhere, it's just my deductive reasoning on the matter.)
    ~If a5 does create indexes as needed, it seems to me that it's not uncommon to end up with redundant & unnecessary indexes. And not only do they "eat up space", but they also (presumably) generate additional "overhead" while maintaining this unnecessary duplication.
    Last edited by SNusa; 01-20-2013, 03:21 AM.
    Robert T. ~ "I enjoy manipulating data... just not my data."
    It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
    RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

  • #2
    Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

    Robert
    I cant see anywhere that a conflict could occur. Every index name is reference with the relevant table. .Index_Set() is used with a pointer to the table either via form name or pointer.
    Am I missing something?

    Comment


    • #3
      Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

      I am almost totally certain "parentform.index_set()" always refers to the parent table on a form with several tables in the set. The only way you could get into trouble with index names would to name the same index for two different fields for a single table; otherwise, there will be no collisions.
      Cole Custom Programming - Terrell, Texas
      972 524 8714
      [email protected]

      ____________________
      "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

      Comment


      • #4
        Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

        Interesting!
        I have bumped into Index issues where the first 8 characters were the same.

        So index names abcdefgh1 and abcdefgh2 for the same table don't always play nicely, but zbcdefgh1 and ybcdefgh1 will get along fine.

        I'm having similar problems with table names (which are SQL names) longer than 10 char. Some won't even display in the Operation Genie, but this might be a version issue which I need to check out.

        While I'm at it, why is there a constraint of 32 char for an index name and only 10 recommended?
        Does that mean it becomes unstable with say 20 charactes as an index name?
        See our Hybrid Option here;
        https://hybridapps.example-software.com/


        There are 3 things you can do in any situation;
        Live with it, Change it or Walk away from it.

        Comment


        • #5
          Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

          index names can become truncated (lops off all after 10)
          used to be a big issue in 4.0 and 4.5

          two things usually cause it to happen

          you give Alpha an query it cannot resolve that uses an index - will sometimes remove the index completely
          copying the dbf from one folder to another where one does not have the current ddd/ddm/ddx

          I have a routine that runs once a day that recreates all indexes from scratch - Selwyn provided an Alpha function for same a few years ago. Also, a user can click a button the recreates the indexes from scratch

          Cal also has a routine for this

          I use table names, field names, and index names maxed out in all three cases, never had a problem
          Cole Custom Programming - Terrell, Texas
          972 524 8714
          [email protected]

          ____________________
          "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

          Comment


          • #6
            Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

            Originally posted by Ted Giles View Post
            Interesting!
            I have bumped into Index issues where the first 8 characters were the same.

            So index names abcdefgh1 and abcdefgh2 for the same table don't always play nicely, but zbcdefgh1 and ybcdefgh1 will get along fine.

            I'm having similar problems with table names (which are SQL names) longer than 10 char. Some won't even display in the Operation Genie, but this might be a version issue which I need to check out.

            While I'm at it, why is there a constraint of 32 char for an index name and only 10 recommended?
            Does that mean it becomes unstable with say 20 charactes as an index name?
            Hi Ted;

            So what you're actually implying here is: To avoid all index issues, index names for .dbf files may actually need be limited to naming conventions using 8 characters and not 10? ~ WOW, "this" number keeps falling......
            ~Within the framework of a5, index names can (in some instances) become truncated to 10 characters, yet a5 can loose it's ability to differentiate between the names @ after the first 8 characters.....

            Also, nobody replied to my second question with regards to when it is actually necessary to explicitly manually create indexes on the tables. (As a5 generates indexes in may instances, and the ones that a5 creates are frequently identical to the ones manually "pre-assigned", with the exception of the index name itself.) ~ I'm thinking that this might be a difficult question to answer "definitively?"
            Last edited by SNusa; 01-20-2013, 03:19 PM.
            Robert T. ~ "I enjoy manipulating data... just not my data."
            It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
            RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

            Comment


            • #7
              Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

              Hi Robert,
              when it is actually necessary to explicitly manually create indexes on the tables.
              When you want the user to do a find a record by dialog, as they type the characters autofill.
              Regards
              Keith Hubert
              Alpha Guild Member
              London.
              KHDB Management Systems
              Skype = keith.hubert


              For your day-to-day Needs, you Need an Alpha Database!

              Comment


              • #8
                Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

                Originally posted by Keith Hubert View Post
                Hi Robert,When you want the user to do a find a record by dialog, as they type the characters autofill.
                Thank you Keith. ~ I suspect I have been defining way too many indexes. I've always built a table and immediately added indexes based on the following:

                1.) "This will be a "parent" record of a table, so it needs to be indexed."
                2.) "I will be setting a primary index on a form in order to do a find."
                2.) "I will be sorting (or searching) on this field, so an index here is important."
                3.) "I may wish to total the values in this field, via calculated fields or via a db_sum() function etc."
                .....I guess that I have been specifying way too many "unnecessary" indexes.... ?
                Last edited by SNusa; 01-20-2013, 09:11 PM.
                Robert T. ~ "I enjoy manipulating data... just not my data."
                It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                Comment


                • #9
                  Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

                  Originally posted by Ray in Capetown View Post
                  Robert
                  I cant see anywhere that a conflict could occur. Every index name is reference with the relevant table. .Index_Set() is used with a pointer to the table either via form name or pointer.
                  Am I missing something?
                  Hi Ray;

                  Providing the following scenario is the case (which I have no reason to believe otherwise), then no:

                  Originally posted by martinwcole View Post
                  I am almost totally certain "parentform.index_set()" always refers to the parent table on a form with several tables in the set. The only way you could get into trouble with index names would to name the same index for two different fields for a single table; otherwise, there will be no collisions.
                  Robert T. ~ "I enjoy manipulating data... just not my data."
                  It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                  RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                  Comment


                  • #10
                    Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

                    I concur with the idea that there should be no conflict with using the same index name in different tables. Other than the possible issue of "what's used where", there should be no conflicts.

                    I only add indexes of my own if I need to use them for a LookupC/N/L() command or if there is some other situation in xbasic where I need a specific index name.

                    If Alpha has already created an index that I need to use for my own purposes, I will often rename it to indicate that it's an index I use for my own purposes. (All index names I create end with an underscore so I can identify them as "mine".) It has been my experience that Alpha will NOT create a new index IF it finds an existing index with *exactly* the same definition including the Filter, Direction, and Include settings. (I could be wrong on this one, there may be situations where that's not true.)

                    I use "special handling" for the indexes that are created by Alpha. First you need to understand that if you delete an index that Alpha needs, Alpha will TRY to create it BUT "try" means there are situations where it can't. For example, someone (could even be you) has TableA open when an attempt is made to open a form (or other layout) based on a set that uses TableA as a child table. In this case, Alpha needs a specific index to create the set but, if it doesn't exist, Alpha can't create it because TableA is already open. This, of course, generates an error.

                    So, when I'm cleaning up indexes, I remove anything that I think isn't needed. Of course, all the indexes ending with "_" are needed. (see note below) After removing all the indexes that I think are not needed, I open every set and every layout - form, report, letter, label - one at a time so Alpha can rebuild any necessary indexes. Of course, opening every one of those manually takes a LOT of time so I built a routine to do it automatically. The automatic method takes about 1/2 second per layout. Those of you that have my AIMS Grab Bag have the routine.

                    Once all necessary indexes have been built, I save the index definitions so I can rebuild to that condition anytime I need to. In my case, I use my Create_index_rebld_auto() function to do that (then my Index_rebuild_auto() will rebuild them whenever needed) but there are other ways. The important thing is to save those definitions in case an index gets lost. Alpha's internal "Rebuild Indexes" routine will rebuild existing indexes but it can't rebuild an index that was lost because Alpha doesn't keep a record of "what used to be".

                    Note: After cleaning up indexes, I KNOW all my "_" indexes that are still listed are needed because I've run my AIMS App Analyzer to find out where all my index names are used and deleted any that aren't used anymore.

                    And, since I've linked to so many of my addons, let me assure you that I didn't write this to sell my addons, if I was doing it to maximize my income I wouldn't be doing it at all because, without even including the time to write these responses, the price of my addons ($19 for those linked) doesn't come close to covering the time I spend updating the addons and helping people who have purchased them. But I do know how much time and frustration they save for me and that's why I mention them - to save time and frustration for others. There's nothing 'secret' in any of the addons. Anyone could recreate them - all it takes is time and effort - and there are often other ways of doing the same thing if you prefer.

                    Comment


                    • #11
                      Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

                      All index names I create end with an underscore so I can identify them as "mine".
                      Thank you. And yes, I use a double underscore at the end to differentiate/designate they are ones that I have defined. I also make a habit of using the field names (without any vowels unless the first letter is a vowel) to "shrink them" down to 8. (There is one in the attachment that I still need to "shrink" to 8 characters.) ~ Because: I've been told that although they can be truncated back to 10, alpha can also have problem differentiating after the 8'th character of an index!
                      ~Apparently, DOS "artifacts" (at the very least) are still "alive & well" in the world of Windows!?!

                      One thing worth mentioning here is: If you specify an incorrect index name (get the spelling wrong etc.) when working with a5 code Xbasic code: One totally unexpected side effect can be that this non-existing (incorrectly spelled) index name may actually corrupt the good indexes. (Which will result in broken browses on forms etc. etc. etc.) Very strange that a miss-typed index name could/would & did result in index corruption!!!!! I just imported a mapped table & form from an older copy of the database I am working on. (one of the calculated fields made reference to an index name that I had subsequently changed.) ~ I couldn't understand why the form was not working. All it took was a rebuild of the mapped tables underlying table indexes, and all was well. ~ STRANGE!

                      I've got to get your "Grab Bag" Cal. ~ I think I'm "ready for it" finally.....

                      PS: IGNORE THE ATTACHMENT HERE. (I can't figure out how to remove it from this post, but the duplicate indexes are are not identical as had thought originally when I added the screen capture.) ~ I should have looked closer at the "include" field.
                      Attached Files
                      Last edited by SNusa; 01-23-2013, 04:26 PM.
                      Robert T. ~ "I enjoy manipulating data... just not my data."
                      It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                      RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                      Comment


                      • #12
                        Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

                        Does all this mean that the following indexes in a set should not work together as they have since about version 3 without any problems?

                        Dave Mason
                        [email protected]
                        Skype is dave.mason46

                        Comment


                        • #13
                          Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

                          Originally posted by DaveM View Post
                          Does all this mean that the following indexes in a set should not work together as they have since about version 3 without any problems?

                          [ATTACH=CONFIG]34555[/ATTACH][ATTACH=CONFIG]34556[/ATTACH][ATTACH=CONFIG]34557[/ATTACH]
                          If you're asking me: I would think they work fine. The problem I had is I imported a mapped table, from an older version of a database that used db_sum(). The index specified in the old mapped table db_sum() parameter no longer existed in the new table. (I had renamed it prior to importing the mapped table.) As a result, no records were being shown on the form. Updating the db_sum() index parameter with the new index name did not fix things until I rebuilt the indexes on the table. (Because I had just rebuilt the index prior to importing, I assumed this is what had corrupted the indexes.)

                          Can anyone comment on the 8 character limit? (a5 may in certain circumstances truncate to 10, but I've recently heard that a5 can also have trouble differentiating after the 8'th character on index names.)
                          Robert T. ~ "I enjoy manipulating data... just not my data."
                          It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                          RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                          Comment


                          • #14
                            Re: Index Names "colliding" in .dbf Sets (internal set index naming resolution)

                            I will.

                            I rarely have a table name, field name, index, form name, report name, adb, or any other more than 8 characters and never more than 10. I learned. It is no fun to open up and find stuff shortened. Am I a bit too careful? Maybe! But it works!

                            I will have a variable, udf or script to 10 letters. I get confused if they are too long anyhow as I came from dos days with 8.3 only.
                            Dave Mason
                            [email protected]
                            Skype is dave.mason46

                            Comment

                            Working...
                            X