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

Referential Integrity Serious Problem

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

    Referential Integrity Serious Problem

    Hi All,

    Please HELP!

    I have a set with many tables, some one to one and some one to many. I have a main form with browses and a tabbed form in which most work on this data base is done.

    There is one particular child table, liked to the parent as one to one, linked by a field called "Link" in each table, with referential integrity set to "cascade changes".

    When entries are made to the fields in the child table on the form, they go to the wrong record. Can anyone think of any reason this may happen? It does not happen with any other table in the set!

    Any help will be greatly appreciated!

    All the best,

    Desperate TR

    #2
    RE: Referential Integrity Serious Problem

    Please excuse my asking simple questions...

    Is the value in the "link" field actually unique in both tables?

    How is this value set?

    When is it set? If you haven't "saved" the parent record before you "begin" the child record what value would go in the link field?

    Is it actually a grandchild table? I have stumbled on this one and had to have a dialog form of the stand alone grand child, not an embedded form. On entering edit mode the pointers would jump to the first "Child" record so I lost my link to the correct "Grandchild" record. Poor set design, I guess.

    Anyway, some thoughts to chew...

    Comment


      #3
      RE: Referential Integrity Serious Problem

      Hi Stephen,

      Thanks for a quick reply! It makes me feel better already!

      As for your questions, of course the "link" field has unique values in each table. In the parent table it is set automatically by a formula taking the first three letters in the ladt name and the first three numbers in the address. If there are less than three numbers in the address then it takes only the numbers there are. The Parent records are always in first. The "Link" field always fills itself in on the form when an enty is made to a field in the child table. This works in all other tables except this one.

      We've been using this form for a long time and it works fine. We just added this table to the set recently. It is a child table but it comes after a grandchild table in the set structure order. I was thinking of testing if that had anything to do with it. The grandchild records work fine, however.

      If you can think of anything, please help.

      Thanks a million for your time and input

      TR

      Comment


        #4
        RE: Referential Integrity Serious Problem

        TR,

        You stated.........We just added this table to the set recently. It is a child table but it comes after a grandchild table in the set structure order.........

        This should have no bearing on the performance of the table. A5 places the child tables in the order in which they were added and it makes no difference whether it's B4 or after a grandchild table.

        Try this, create a test set of only 2 tables, the parent and this child table. See if that will work. My guess is it won't unless the link is different from the present link. As Stephen says, I suspect your problem is in the link.

        kenn
        TYVM :) kenn

        Knowing what you can achieve will not become reality until you imagine and explore.

        Comment


          #5
          RE: Referential Integrity Serious Problem

          "of course the link is unique"... Did you check? Sometimes Murphy works his mischief in the most obvious ways. Gotta be thorough... I have bruised my head over not "checking" the simple stuff before.

          Maybe you have two clients with the same three letter last name and same three number address. This is quite possible, and not that unlikely. I did almost exactly this till I had a duplication. Now I use a customer ID that is incremented automatically. Each Job has a Job ID, that is also incremented automatically. I also have a job code that is set manually, but has a check for uniqueness... The code is easier to remember like Tovia01 for your stuff in 2001.

          Anyway - go look for duplicates...

          Comment


            #6
            RE: Referential Integrity Serious Problem

            TR,
            Link() is an xbasic function. I recommend that you do not use function names as names for fields in your table, or as names for objects on your forms. It's possible Alpha Five is having trouble here simply because of the field name.
            -- tom

            Comment


              #7
              RE: Referential Integrity Serious Problem

              Hi Ken,

              I really appreciate your interest and assistance. I am sitting at different computer now and I don't have access to my files. However I did already try a small set with only the parent and this child table, and it does work. I am not surprised that it did, because it should.

              I am using Alpha since A4v3, and I order every upgrade as soon as it is released. As a matter of fact I can't wait for A5v5. I am also using this set and form for several years. I keep updating it constantly, depending on the needs of my client. I have never ran into a problem like this!

              I know I probably did something wrong, but I am usually a good troubleshooter. I am turning to the forum because I am stumped.

              Needless to say, any help will be greatly appreciated.

              All the best

              TR

              Comment


                #8
                RE: Referential Integrity Serious Problem

                As a suggestion:
                Try the default form for the set and see what happens. That
                will let you know whether the problem is with the set or
                with the form.
                - Peter

                Comment


                  #9
                  RE: Referential Integrity Serious Problem

                  Stephen,

                  We don't have any duplicates, and the field is protected not to take duplicates. Besides, what's most intriguing is that we are using this form successfully with several one to one as well as several one to many child tables (with browses) for several years, and we never ran into this problem.

                  I update and modify the form from time to time as needed by the client. I remove or add tables to the set, and modify the form, etc.

                  Thanks a million for wasting your time, and please write as soon as you think of something. Likewise I will report as soon as I have it solved.

                  All the best,

                  TR

                  Comment


                    #10
                    RE: Referential Integrity Serious Problem

                    Hi Tom,

                    I am flattered that my post drew so many responses, and from the top guns yet. Thanks for taking the time.

                    I use the label "Link" for the id field in every table. It always works well, for years now. As a matter of fact it works in this very table with small test sets.

                    I really appreciate your taking the time to look into my problem, and I will appreciate even more if someone will find the answer.

                    As soon as this is resolved I will post the answer.

                    All the best,

                    TR

                    Comment


                      #11
                      RE: Referential Integrity Serious Problem

                      Hi Doctor,

                      I can't tell you how much I appreciate your taking the time to try to help me. I am not sitting at my computer now so I can't try your suggestion right now. But it sounds like a great place to start.

                      The only problem is that I have many fields in the parent table, and with several tables before this in the set structure, I don't think this table will get on to the default form. Whenever I press "View" from the control panel I get the message that the form is full and not all fields fit.

                      As soon as I get any clue I will post it promply.

                      All the best,

                      TR

                      Comment


                        #12
                        RE: Referential Integrity Serious Problem

                        TR,

                        As a suggestion, take the time to create a browse containing the link fields and another field or two for id purposes. You might be amazed what you'll find.

                        Also, Tom's suggestion about the Link() function should not be ignored just because it worked well in the past. You've added another table with a link field and that one extra field called LINK may have pushed it over the edge. Stephen's advise about checking the little obvious things turns up the error more often true than not.

                        NOTHING should be eliminated just because it worked B4.

                        kenn
                        TYVM :) kenn

                        Knowing what you can achieve will not become reality until you imagine and explore.

                        Comment


                          #13
                          RE: Referential Integrity Serious Problem

                          Ken,

                          I do appreciate your points.

                          I will try the browse idea as soon as I get to my computer. I am starting to think that you guys may be right about naming the Link field "Link", even though it did work in the past, as you and Tom suggested.

                          So... Resolved: 1) I will try to avoid naming fields, especially linking ones or other important ones tha same as internal labels, but more impotantly: 2) As soon as I get to my computer I will see if renaming the linking field and relinking this particular table will do the trick. I suspect it just might:)

                          I will keep you all posted.

                          Thanks again,

                          TR

                          Comment


                            #14
                            RE: Referential Integrity Serious Problem

                            Hi All,

                            Here is the update I promised when I found a solution to the problem.

                            The entire problem was caused by a new form called by a button on the main form labeled "Find". I created this new "Find" procedure to make it easier for the input people to find an existing record. The button called a form with a browse that utilized a line-double-click-event to return to the main form with the sought record displayed.

                            It seems there is a problem somewhere in my code that messes up the referential integrity of the set. When the record was selected not through this new "Find" button and form, there was no problem. Even when the record was selected through the "Find" button and form, gettin the wrong child record, if we escaped without saving the child record and then went back in, it did bring the right one.

                            So there... another mystery solved. There is a certain pleasure I'm sure you all experience at some time, when a nagging problem is solved, so you know how I feel now.

                            Thanks everyone for your interest and help. What a beautiful family of users this is.

                            All the best,

                            TR

                            Comment

                            Working...
                            X