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

Refresh Issue

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

    Refresh Issue

    Hi All

    I've got a straight forward stock order form with an embedded browse containing the parts information.

    Capture.JPG

    In the main body of the form I have several summary fields that calculate the total number of parts ordered, total cost, ect. These fields are calculated through the "Field Rules" using the tablesum() code. (See full code below) This code seems to be working just fine on it's own.

    Code:
    TABLESUM("data_stock_order_parts.dbf","id_or = '"+ORDNUM_OR+"'","qtyor_por")
    The problem I am facing is that when I add a new record to the browse, these calculated fields do not refresh. I've tried using various refresh methods but none have worked. However, if I enter a new record in the browse then change a field in the main body of the form then select a different field the calculated fields refresh with the correctly calculated data.

    Any idea on how to correct this?

    #2
    Re: Refresh Issue

    Table level field rules? You'll have to commit the form record and resynch the form to the table.
    There can be only one.

    Comment


      #3
      Re: Refresh Issue

      Or - use calculated fields at form level that mirror the table calcs.

      Comment


        #4
        Re: Refresh Issue

        Hi Ray...I actually tried that, but when I save the form the calculated fields in the table do not update. It's as if the data was never entered into the child table.

        Comment


          #5
          Re: Refresh Issue

          Calculated fields' values are not expected to update the table (unless you instruct them to) - your table is being updated by the field rules as I understand it - this was suggested to reflect on the form.

          Comment


            #6
            Re: Refresh Issue

            My viewpoint after working with Alpha since the DOS days and writing many, many apps....

            Avoid using calculated fields in TABLES as much as possible. If you think you need a calculated field in the table, think again because you probably don't. Most calculated fields (at least 90%, and probably much more than that, of the ones I've seen used) don't need to be saved because they can be calculated on the FORM (or report or other layout) just as easily. AND, when a layout level calculated field is used, it will be re-calculated immediately upon making any change to any other field it references. Table level calculated fields will not 'refresh' until the record is saved.

            Come on - does Qty*Cost really need to be saved as a calc field in the table!? Just calculate it on your form or report when you want to display it.

            It's very, very, very, very rare for me to use a calculated field in a table. I know I've done it in the past (in the distant past it was more often than necessary but still uncommon) but it's so rare now that I have no idea where any examples would be. The only time I would do it is when nothing else works acceptably. For example, if I need to sort a large table on something that requires a very complicated calculation AND running that calculation to sort the table makes the sort take way too long, I'll probably add the calculated field to the table. HOWEVER, I'll still use the calc field in my layouts because it refreshes before the record is saved.

            Another place I considered using one was in a situation where the color calculation for a field in the browse was taking so long that the browse flashed for about 30 seconds every time the form was opened or activated. The problem was that the color calculation required running a table.external_record_content_get() on the child table and then a search of that text string for a specific value on every record. That meant a new query was run for every child record and when the table started getting large (much larger than my original test data unfortunately) the time to run all those queries was - well, let's just say the customer wasn't happy. We solved it - we decided the color wasn't really that necessary and there were other ways to deal with the issue.

            Comment


              #7
              Re: Refresh Issue

              Cal. I am also one intrinsically against table field rules - they can be an albatross around the neck.
              There was one form in an app of mine that was plagued with a random error.
              Eventually when I found the root cause (weeks later - intermittent errors are the hardest to fix, try something, tests as fixed, send it back and later goes wrong again).
              The long term permanent solution came from resorting to set level field rules. Here a the child level calculation included a parent value reference.
              What was happening:- on the browse line where the calc is done (using event events) something internal to alpha was pointing to the top line of that browse and calculating the wrong line's value.
              I have it resolved, as I said , using field rules in tables (set)
              If you would be so inclined ( to see that example, and try resolve the problem )
              I will set up a demonstration of the original problem and send it to you - for academic purposes but maybe practical as well.

              Comment


                #8
                Re: Refresh Issue

                Ray,

                Yep! There's an exception to every rule.

                I'll PM you about an example. It would be interesting to see.

                Comment


                  #9
                  Re: Refresh Issue

                  Thanks for your advise Cal.

                  I've removed the calculated fields in the table as you suggested.

                  Comment

                  Working...
                  X