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

Posting Field Rules

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

  • Posting Field Rules

    Have posting field rules in some tables, but not all fields with the rules get posted and after working for 5 hours on it, I still can't figure out why. Have attached a zip of the in-progress app.

    Field Rules: (posting to annual_plan table)
    Open inc_totals table.
    Field ap_plan has a posting field rule that works.
    Field ap_actual has two posting field rules, neither of which work.
    Open exp_totals table.
    ditto.......

    Open annual_plan_form
    Press NEW Income Sheet or NEW Expense Sheet
    This will open inctotals_form or exptotals_form
    Enter an amount in the Monthly Plan field. You can then save/close the form and this amount will get posted back to annual_plan table. Or you can add an item to the embedded browse which will update via field rules the Monthly Actual field. Now save/close the form to go back to the annual_plan_form. The Inc. Plan / Exp.Plan fields will have been updated, but not the Inc./Exp. Actual fields. Also the bank_bal table is not getting updated.
    Hope somebody has time to take a look and let me know what I've screwed up.
    Thanks.
    Ernie

  • #2
    Re: Posting Field Rules

    As an addition I meant to put in there, the field rules do work when using the default browse or form. So there must be something in the forms as I've designed them to prevent them working on each field.
    Ernie

    Comment


    • #3
      Re: Posting Field Rules

      Ernie, your additional information suggests that you are expecting the post field rule to fire when you enter or change field values using a script. This expectation is misplaced. Post field rules fire when field values are entered or changed using a form or browse layout. i.e. when field values are entered or changed by the user through the keyboard. The post field rule does NOT fire when field values are entered using a script. Might this explain what you're seeing?

      Comment


      • #4
        Re: Posting Field Rules

        Tom,
        No. What my additional statement is saying is that my field rules work from the default browse and form but not from my form. I have not script that has to do with updating the field. I enter a value in a field and save the record.
        Ernie

        Comment


        • #5
          Re: Posting Field Rules

          Ok. Sorry. I'll take a look. -- tom

          Comment


          • #6
            Re: Posting Field Rules

            Now save/close the form to go back to the annual_plan_form. The Inc. Plan / Exp.Plan fields will have been updated, but not the Inc./Exp. Actual fields. Also the bank_bal table is not getting updated.
            Ernie, I see this. The post field rule you defined in the exp_totals table for the AP_PLan field, seems to be working fine. It posts the value entered by the user to the Exp_plan field in the Annual_plan table.

            But I don't see (and you haven't told us) why the Inc/Exp Actual fields in the Annual_plan table should be "updated" automatically, when only the Monthly Plan field is edited. What am I missing?

            Using an Expense transaction walk us through a single transaction without skipping any steps. Tell us:

            a) what should happen, using actual form, field and table names; and

            b) what you've defined to make "it" happen i.e. where does it seem to be broken... or what you're seeing instead of what you are expecting.

            -- tom
            Last edited by Tom Cone Jr; 10-03-2008, 11:50 AM.

            Comment


            • #7
              Re: Posting Field Rules

              Here is the situation as best as I can explain it.

              Three tables I'm working with:
              annual_plan
              inc_totals
              inc_details

              annual_plan table has two fields to update: Plan and Actual from the table inc_totals related by annual_plan ID.
              inc_totals has two field: Plan (manually updated) and Actual (updated via child table inc_details)

              From the annual_plan_form, I call a form, inc_form, to add a record to the table, inc_totals, related by the annual_plan ID number. This form has two fields, Plan and Actual, that are used to post to the similar annual_plan table fields. The inc_totals field, Plan, is manually entered/updated. The inc_totals field, Actual, is updated via a child table, inc_details.

              Before I call an inc_details_form, I save the current inc_totals record to establish a record in the inc_totals table. This posts the Plan amount, say 1500, to the annual_plan Plan field and 0.00 (zero) to the annual_plan Actual field.

              Then inc_details_form is called to add a details record. The Amount field in the inc_details_form updates the inc_totals Actual field, which it does.

              Now I am back to the inc_totals_form with a new updated value in the inc_totals Actual field. However, it isn't showing that any changes have been made and therefore nothing needs to be saved in the inc_totals_form. And so my posting field rules to the Actual field in the annual_plan table doesn't fire.

              When I first save this inc_totals record, I have a value in the inc_totals Plan field and this value updates the annual_plan Plan field. The inc_totals Actual value field is null/zero. After adding the details record, the inc_totals Actual field changes to the new value, but it isn't recognizing that anything needs updating. If I manually change the inc_totals Actual field say from 1000.00 to 900.00, it will post -100.00 into annual_plan Actual. If I leave it as 1000.00, the annual_plan Actual value remains at 0.00.

              I'm certainly not understanding why it works this way. Can somebody enlighten me? I would sure appreciate it.
              Thanks.
              Ernie

              P.S. Tom, just saw your post after submitting this one. I'm using the name, inc_form, instead of inctotals_form as in the Zip file. I hope my explanation above clears it up a bit for you. The Income and Expenses are used basically as worksheets that update totals in the annual_plan table/form. I am trying to simulate an Excel program.
              Last edited by enstorms; 10-03-2008, 11:53 AM.

              Comment


              • #8
                Re: Posting Field Rules

                Do not expect the post field rule in the Inc_Totals table to fire when the Inc_Actual field is updated from the Inc_details form. That's exactly the kind of non-keyboard input that I was describing before. This probably explains why the post works when you manually change the Inc_Actual field value, but not when you change that value from the Inc_Details form. Hopefully this makes sense to you and answers your question. Let me know if you need me to look further.

                For the benefit of other readers, let me try to describe Ernie's problem differently.

                Transaction details are recorded manually in a table.

                The transaction table has a post field rule that updates a related field in a second table.

                The second table has a post field rule defined for the "related field" that is receiving updates (via post rule) from the transaction table. The post field rule in the second table updates yet another related field in a third table.

                The post to the second table is working. The post to the third table is not. Presumably because the field is being updated via the post field rule defined in the transaction table, and NOT being manually edited by the user.
                Last edited by Tom Cone Jr; 10-03-2008, 02:08 PM.

                Comment


                • #9
                  Re: Posting Field Rules

                  Tom,
                  Thanks so much for your efforts in this explanation. I had come to the same conclusion after my last post. My "third" table was updating the second table which doesn't fire the post rules of the second table. So now I'll have to change my strategy on how to get this done. I did have it working before by using a calculated field for the inc_totals->Actual field, then updating that field before saving/closing the form. But thought why not have my details table update it instead. Now I know.
                  Thanks again for all your help.
                  Ernie

                  Comment


                  • #10
                    Re: Posting Field Rules

                    Ernie,

                    Using Tom's terminology, since you want the third table's value (inc_details) to not only be posted to the second table (inc_totals) but also to ultimately be posted to the first table (Annual_Plan) then add a second line in the posting rule in the inc_details table.

                    This second line (rule) would post directly to Annual_plan table. The tricky part is getting the link between the two tables. below I have copied the line I used. The portion in red is for the source linking expression and as you can see I used a lookup to the inc_totals table to get the correct aplan_id.

                    Code:
                    annual_plan.dbf    annual_plan->Inc_Actual    Aplan_Id    [COLOR=Red]lookupn("F",Inctot_Id,"Aplan_id","inc_totals","Inctot_Id")[/COLOR]    Add         Yes
                    Although this technically does what I think you want make sure you test it to make sure it does not interfere with other parts of your app. In my limited testing it seems to do the right thing including still allowing manual adjustment from the inc_totals table. (not that you probably would do that though)
                    Tim Kiebert
                    Eagle Creek Citrus
                    A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.

                    Comment


                    • #11
                      Re: Posting Field Rules

                      Tim,
                      Thanks for the suggestion. What I have done is pass the aplan_id from inc_totals to inc_details so it can relate to annual_plan.dbf. Then I have inc_details Actual post to annual_plan Actual. Don't know if this is a good way to do it or not, but it works.
                      Your suggestion made me realize I can put an expression in the key field instead of just a particular target/source field. Guess that's why they call it an "expression builder".
                      Thanks again, Tim.
                      Ernie

                      Comment


                      • #12
                        Re: Posting Field Rules

                        Your welcome. If it works it works. :)

                        The way you have done seems like basically what I suggested except that you are getting the linking key by passing the Id fields down through the tables. Either way has its pros and cons. Passing primary keys down through child tables is more work in setting it up and making sure of integrity. But using a lookup in the expression has bit of a performance cost.

                        Cheers, Tim
                        Tim Kiebert
                        Eagle Creek Citrus
                        A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.

                        Comment

                        Working...
                        X