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
Devcon 2020 Goes Virtual! LEARN MORE >

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

form to enter/edit child records

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
    #1

    form to enter/edit child records

    I believe I've seen several references in the past to folks who prefer to enter records in a child database in a set through a form that is opened rather than in an embedded browse on a form that displays child records.

    Does anyone have a concise explanation of how that might be done?

    Thank you.
    Tags: None
    #2
    RE: form to enter/edit child records

    Paul,

    I'll take a stab at this w/o having tried it out, maybe I'm close and then again, maybe not.

    1. I'm thinking there would have to be an existing parent record so if you build the form based only on the child table, you would need to have a lookup expression to pull in and existing link.

    2. Another way would be simply to create the form based on the set but with only the child fields on it other than a linking field from the parent table which could be a lookup field to pull in the linking value.

    Not too close on smoe ideas but we'll see how close I am on this one.

    kenn
    TYVM :) kenn

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

    Comment

      #3
      RE: form to enter/edit child records

      An explanation, yes. Concise, well, maybe not.

      One key advantage to doing data entry to the child table using a form based on the set, is that Alpha Five is aware of the link between parent and child table. As new records are added to the child table the correct link field value is stored in the child record for you. The user doesn't see that field, and can't mess with it. This increases the chances that they won't destroy the link and create a bunch of orphaned or mismatched child records.

      One disadvantage is that the embedded browse for the child table doesn't have all the nice events available during data entry that are available using a form. Users sometimes enter lots of blank records, and so on.

      If you want to use a second form for data entry into the child table, which I often do, you must remember a couple of key things:

      1) you must pass the link field key value to the corresponding link field in the child table yourself. Alpha Five won't do it. (You can use global variables for this, or you can have the called form 'look back' at the calling form and read values off objects on the form). I strongly recommend that you make the key field read only in the called form.

      2) when you open the second form you create a second 'instance' of the child table, you must then navigate to the correct record if an edit is desired. Otherwise the form opens up looking at the first record in the table. (You can navigate with an index find based on a key field value, or recordnumber)

      3) when the called form closes, remember to resynch the calling form if any of the child table fields are displayed there. The calling form won't be aware that data entry has occurred to the child table, so the user won't be able to see the changes until a resynch() or refresh() occurs.

      Hope this helps.

      -- tom

      Comment

        #4
        RE: form to enter/edit child records

        I have some data entry in both formats. One issue with the form, mentioned in Tom's item 3), is resynchingrefreshing. Unfortunately Alpha Five is a little reluctant at times to do this job smoothly. I am experimenting with closing the set form as part of opening the child form, then reopening the set form as part of closing the child form so the data is read fresh. None of these difficulties occur using an embedded browse.

        New thought, fresh off the boat, embedded forms activated by a button to enter the child data... Put them on top of a browse, then hide the browse, show the form. Or put them on a conditional object, condition being a variable "EnterChild" or some such. Alpha Five has SO many alternatives this thread is a good one. I hope others will share their experience.

        Comment

          #5
          RE: form to enter/edit child records

          Paul,

          As a followup to my response, this is how I do it.

          I base my forms on a set. I use the main or master form based on the parent table of the set, using only key fields. Then, I drop a tabbed form on the master form. This works out extremely well since I use a tab for each child table. I also place the child table's fields on a tabbed page if the child table is a 1:1 relationship. (I do not put forms on the tabbed pages, that is redundancy)

          For tables with a 1:many link, I put an embedded browse (child table) as well as calculated fields. I do use the embedded browses for data entry. (Some folks don't like that approach) Of course, this can depend on the type of data you need to enter. In my case, I'm continually entering dates so it's very handy to be able to see what's been entered and know where to take up where you left off.

          I do use a form for Query by Form, Find by Form, Filtering, sorting, etc., which is not based on the set, but rather a child table. I place the key fields of the table above an embedded browse. Once records are queried, filter, sorted, etc, I have a button that says, Print It!!

          I've never had a problem with this kind of setup and switching from tab to tab is faster than switching from form to form, plus, it's less work than creating several forms for data entry. Perhaps there are some disadvantages to this other than personal preference. But to date, I found that you must use a browse for data entry in 1:many relationships but that's not necessarily a disadvantage, at least not for me.

          Summary: The neat thing about a tabbed sub form is that, as both Tom and Stephen indicated, you need the integrity of the linking field. There is no problem with integrity with this setup.

          Hope this provides some insight.

          kenn
          TYVM :) kenn

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

          Comment

            #6
            RE: form to enter/edit child records

            Stephen,

            Your last thought has some real possibilities. I haven't had time to really work it all the way through, but a quick test on a form I already have that contains an embedded browse for child records shows that adding a subform displays child records in perfect synch with the browse. All that's left are the details about making one disappear as the other appears, and that shouldn't be too tough. I really like solutions that minimize the amount of programming required.

            Thanks to all who contributed ideas.

            Paul French

            Comment

              #7
              RE: form to enter/edit child records

              Along the same lines, I have a set that has a limited number of child records, where I want to show just one at a time. Instead of using an embedded browse for entry and display, I just place the child fields directly on the form. I also use a very small embedded browse on the form that is read only and has all of it's colors set to the same as the background, thereby making it invisible.

              When the form opens, it shows the first child record on the form. A "next" button takes focus to the browse and fetches the next record, then returns focus back to the button. I tried hiding the browse, but then the form doesn't want to resynch correctly. With a little xbasic work, I also created a button to enter a new record using the fields on the form.

              I am still in development, but it seems to work well.

              Jerry

              Comment

                #8
                RE: form to enter/edit child records

                Ok - I am also finding this works well. I have a tabbed object and as a "quickie" added a tab to hold the embedded form to enter child record data. It works great as regards synchronising data. I have been futzing with dialog boxes and refreshes and not getting the necessary reliability of display. Till now.

                Comment

                Previous template Next
                Working...
                X