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

Minimizing Network Overhead question

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

    Minimizing Network Overhead question

    From the help file for Minimizing Network Overhead:

    When entering a new record, programmatically begin a new record and save it immediately, then present it to the user in change mode.
    Can someone elaborate on what the reasoning is behind this statement?

    What is the advantage in having a record in Change mode as opposed to Enter mode?

    Bob Arbuthnot

    #2
    Re: Minimizing Network Overhead question

    Hi Bob,

    I's say this statement is wrong unless others have something viable to say.

    Having a table in change mode locks the record until saved and uses network bandwidth at change and save times. Enter does not lock any record while open, and uses network bandwidth only at save time, same as change mode.

    The only difference, is primarily with auto-increment fields. Alpha uses the increments the maximum value in the table of the field at enter time, and at save time determines if the incremented maximum value has been saved by another enter at a different station, and then recomputes things based upon that new maximum. If you immediately save an enter, then that initial autoincrement number will be the one you get.

    But does it say network overhead? In fact, change mode uses more.
    Regards,

    Ira J. Perlow
    Computer Systems Design


    CSDA A5 Products
    New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
    CSDA Barcode Functions

    CSDA Code Utility
    CSDA Screen Capture


    Comment


      #3
      Re: Minimizing Network Overhead question

      Seems to me the issue here is not in regards to locking the record, but rather "Network Overhead".

      Locking the record is not a concern here being a new record.

      When adding a new record, granted you are not locking any records BUT you are placing the table in Enter Mode. While you are in enter mode alpha allocates part of the memory as a buffer to hold all the tenative data. And that's the overhead alpha is referring to.

      That said, one could argue against that since placing the record in change mode requires the same or almost the same buffer. One could only speculate that it does not since the data are now bound.

      The concept might be legit, however it's fraught with adding blank records.

      Comment


        #4
        Re: Minimizing Network Overhead question

        No disagreement with either Ira or Gabriel; especially the fact that "it's fraught with adding blank records."

        To add a bit more clarity to the auto-increment issue. There have been instances where two people are entering new records in a form based on a set and both get the same auto-increment number for the parent record during the ENTER process because neither record has been saved. Since the form is based on a set, there is also a browse of child records on the form. Then the first person saves the parent record and starts adding child records. (Of course, just moving to the browse saves the parent record even if the user doesn't specifically push a button or press F9 to save the record.) Those child records also start to show up in the browse on the second person's form - after all, they have the same linking value for now. This is very disconcerting to the users and usually results in a panic call to the developer.

        When this happens in your app, you have to chose between (1) "no interaction between child records during data entry" and (2) "a significant risk of adding blank [or half completed] records" because a simple 'Cancel' will no longer remove a record that has already been saved.

        Of course, most of us want to avoid the interaction issue but still find a way to automatically delete an incomplete record - kindo' like hitting the 'ESC' key. However, that basically falls under the Catch-22 clause. (For those who don't know, a Catch-22 is basically a no-win situation.) The objective is to delete any incomplete record BUT that same record must initially be saved as an incomplete record in order to solve the "interaction" issue. Of course, you could initially save the record as a complete record filled with default data but then the user would actually have to delete the default data in order to invoke the "automatic" delete routine - might as well just put a Delete button on the form and hope it will get used. Perhaps it could be accomplished with careful application of table field rules vs. form field rules but no matter how it gets done, it's likely to get complicated.

        Comment


          #5
          Re: Minimizing Network Overhead question

          Ira, Gabe, & Cal,

          No arguments from me. I couldn't see any reason for doing this. There have been times in the past when I've tried to follow the recommendation and it makes for a lot more work when you try to give the user the option to cancel out of a new entry.

          If you 3 say it's so, I feel pretty safe in going to the bank with that consensus.

          Thank you for your thoughts and considered opinions!

          Bob Arbuthnot

          Comment


            #6
            Re: Minimizing Network Overhead question

            Here's a real life case - at a hospital, (after a windows update - maybe 2 years ago,) we started having a humongus (sp?) time lapse when entering and saving a record. I changed to creating the record first in a way (parentform:tables.tablename) that made it instantly visible in an embedded browse on the first form, got the recno(), and then opened a child form displaying the record. Previously, I was opening the child form and entering a new record. It made a difference of several hundred percent. But I only had to do it for one therapy type. All the others which are quite different didn't need the special treatment.

            Whether you need to do it would depend on performance. But for memo fields it is ALWAYS recommended - see Dr. Waynes advice
            Cole Custom Programming - Terrell, Texas
            972 524 8714
            [email protected]

            ____________________
            "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

            Comment

            Working...
            X