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

Updating parent rec. based on child values.

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

    Updating parent rec. based on child values.

    Hi
    I am trying to update a parent record status field to 'Completed' when all its child records have the status of 'Completed' set. The ideal scenario would be for this to happen immediatley when the final outstanding child record status is changed on screen by the user.
    Also can anyone recomend any good books at this level?

    I have had a look through the various forums but to no avail. If anyone can help it would be a real life-saver!
    Thanking you in advance,

    Darrel

    #2
    RE: Updating parent rec. based on child values.

    I think you'll have to script this for the ondepart event for the child record status field, possibly on the data entry maintenance form. The ondepart event would fetch through the related child records and if none were incomplete, it would write completed to the parent record.

    You don't specify what would happen if a new child record was added or if a child record is changed back to incomplete. Have you condidered those possibilities?
    There can be only one.

    Comment


      #3
      RE: Updating parent rec. based on child values.

      Thanks for the reply Stan. I am assuming (without any A5 knowlege!) that some sort of iteration of the child records would take place to check each records status and as such, if a status had been changed from completed or a new chilld record were to be added, they would be caught-up again in the itteration process.
      I was trying to stay away from field rule pocessing as the table to which the child records belong is used by different screens.
      I guess i'm looking for an example of referencing child records while maintaining the relationship of the parent. I have no experience of this sort of programming although I have worked with Db languages on the big 'ol mainframes.
      Any pointers?

      Thanks,
      Darrel

      Comment


        #4
        RE: Updating parent rec. based on child values.

        You really have four possibilities and only one of them involves checking other child records.

        1. Child record is set to true (completed) and parent status is already true. - take no action
        2. Child record is set to false and parent is true - set parent to false
        3. Child record is set to false and parent is false - take no action
        4. Child record is set to true and parent is false - need to check if any other child record is still false

        this could be handled by setting the parent record to true and fetching through the related child records changing parent back to false if a false child record is encountered.

        "I was trying to stay away from field rule pocessing as the table to which the child records belong is used by different screens." - I didn't mention field rule processing. You are allowed to code the "events" for a form such as departing/exiting the field as represented on the form.
        There can be only one.

        Comment


          #5
          RE: Updating parent rec. based on child values.

          Darrel:
          Few ideas come to mind, the easiest would be to use "post":
          a-If you enter a new record or modify an existing record's staus to incomplete (or blank or anything other than complete) it will post "Incomplete to the parent
          b-If you modify the status to "Complete", it will so post to the parent.
          Gabe

          Comment


            #6
            RE: Updating parent rec. based on child values.

            "a-If you enter a new record or modify an existing record's staus to incomplete (or blank or anything other than complete) it will post "Incomplete to the parent" - he's already stated he didn't want to use field rules

            "b-If you modify the status to "Complete", it will so post to the parent. " - if you modify the parent record based on one child record, what about child records that are not complete?
            There can be only one.

            Comment


              #7
              RE: Updating parent rec. based on child values.

              Stan:
              This will work more like a switch that you turn on and off:
              1-Let's start out with the parent record and no child records:
              The status field in the parent record will be empty (or has something other than complete).
              2-Now add a child record. The status field in the child record is either empty or incomplete. When you save that first child record, it will post "incomplete" to the parent's field.
              3-Sometime later, you modified that first child record to complete, when you save the changes, it will post to the parent field "complete".
              4-Now add a second child record, the status in this one is either empty or incomplete (anything other than complete), when you save it, it will post to the parent's field "incomplete".

              You see how it's switching back and forth based on what you do with the child records?
              Gabe

              Comment


                #8
                RE: Updating parent rec. based on child values.

                Oupssssss!
                I just realized a glitch in this protcol !! it won't work. Sorry.
                So now, off to plan B:
                create a calc field in the child table: if(status="complete",1,0)
                In the parent table, the status field will be a calc field:
                if ( dbmin()=0,"Incomplete","Complete")
                Gabe

                Comment


                  #9
                  RE: Updating parent rec. based on child values.

                  ...Or...
                  Plan C, this is a better one, still using "post" :
                  1-Convert the status field in the parent table to numeric
                  2-Whenever you add a new child record or change the child's status field to anything other than "complete", it will post -1 to the parent
                  3-whenever you change the status to "complete", it will post 1
                  4-Create a calc field in the parent: if(Status"0,"Incomplete","Complete")

                  This scheme assumes that, when you enter a cild record for the first time, the status field is either empty or incomplete but is not entered as complete right off. If that is the case, it won't work (unless you do some other modifications).
                  Gabe

                  Comment


                    #10
                    RE: Updating parent rec. based on child values.

                    Here's an example of a form ondepart event triggering a change in the "parent" status field when all the "child" linked records have their status set to true. I use quote marks because the set used here is inverted. What would be a one parent record to many child records is set up so that many child records are linked one-to-one to the parent records.

                    Of course this is worth exactly what you are paying for it so when (not if) you find a problem with it......
                    There can be only one.

                    Comment

                    Working...
                    X