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

How to ensure succesively run scripts complete before the next script runs?

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

    How to ensure succesively run scripts complete before the next script runs?

    I have a daily data housekeeping requirement that consists of 31 sequential scripts that includes: table zaps, text and spreadsheet file imports, appends, posts and calculation updates.
    I am worried that running them as normal in succession might cause problems. I appreciate that I should run them to see for myself (messy to restore afterwards), but I thought it best to ask here first...
    So, I wondered if there are likely to be timing problems, is there a simple way to avert this.
    I appreciate that I could add a delay at the start or end of succeeding scripts, but how long is a piece of string?

    Paul

    #2
    Re: How to ensure succesively run scripts complete before the next script runs?

    If these are all xbasic (no javascript) then all routines will run in sequence without overlap or collision. If you have them as separate pieces of code under buttons, or separate A5W pages, or similar, you do need to insert a method to know when each is done before starting the next. I have used this method to string multiple A5W page-based scripts together:

    <%a5
    do this
    do that
    request.redirect("script2.a5w")
    %>
    Steve Wood
    See my profile on IADN

    Comment


      #3
      Re: How to ensure succesively run scripts complete before the next script runs?

      Thanks Steve, they are all xbasic separate scripts run sequentially from one button using actionscript 'OnPush' event.

      So this should be OK - right?

      Comment


        #4
        Re: How to ensure succesively run scripts complete before the next script runs?

        Yes all run sequentially. You actually could not run more than one process at the same time without specifically starting a new "session".
        Steve Wood
        See my profile on IADN

        Comment


          #5
          Re: How to ensure succesively run scripts complete before the next script runs?

          That's good to know.

          Thanks again,

          Paul

          Comment


            #6
            Re: How to ensure succesively run scripts complete before the next script runs?

            Paul, if this is for a desktop app then I think you may be headed for timing problems if your "master" script consists of a xbasic code that calls a series of operations, or manipulates the tables directly. You may not safely assume that the master script will wait for a called operation to complete before it moves on to the next statement in the master script. (I suspect that Steve was in Web App mode when he responded to you. Or maybe I'm missing something in your original post?) The solution on the desktop is to wrap the batch operations and the direct table manipulation code in their own user defined function. When the "master" script calls a function it waits for the function to return a value, causing the processing of the master script to pause. Using the "sleep" statement will not suffice. So, a lot depends on how the master script is coded. -- tom

            Later: See posts 8 & 9, below. Its possible the script_play() function might cause the "master" script to pause.
            Last edited by Tom Cone Jr; 01-24-2013, 09:06 AM.

            Comment


              #7
              Re: How to ensure succesively run scripts complete before the next script runs?

              Hi Tom,

              I must admit I suspected that.
              I have run it as a sequential list and it worked OK (apart from some other unrelated minor coding bugs), but who is to say that on future days on different PCs it will not prove problematic in this form...
              So, I will take your advice and wrap each as a function.

              Thanks,

              Paul

              Comment


                #8
                Re: How to ensure succesively run scripts complete before the next script runs?

                In support of that, I found that even the function script_play() appears to complete before returning.*
                So you dont need to couch your code in their own functions.

                *I haven't done extensive testing but I found that a particular screen refresh happening at the end of a set of complex code segment was refreshing prematurely.
                Calling the code from the button with script_play and then the refresh thereafter on the button works a charm.

                Comment


                  #9
                  Re: How to ensure succesively run scripts complete before the next script runs?

                  Ray, I appreciate your post. As I think back on the times I've had trouble I was not actually using the script_play() function, instead it was all "inline" code, calling a series of operations, or manipulating tables directly in xbasic. So I guess the correct answer to Paul would be to ask him to show us his code so we can exactly what's happening.

                  And see Ira's "tip" recommending the use of functions instead of scripts throughout our applications.
                  Last edited by Tom Cone Jr; 01-24-2013, 09:09 AM.

                  Comment


                    #10
                    Re: How to ensure succesively run scripts complete before the next script runs?

                    Hi,

                    Just got back home. I will try both ways. At the moment it is just a sequential list of scripts actioned on a form button's 'OnPush' event.
                    Each script is a modified (for daily file-names) version of the xbasic source offered at operation level. Nothing fancy.
                    I remember Glen Schild once advised me to use functions wherever possible, based on Ira's work I guess.
                    Changing to functions may permit me to re-use similar code requirements and reduce the number of scripts required...
                    Any way, we'll see. Thanks for all the help.

                    Paul

                    Comment


                      #11
                      Re: How to ensure succesively run scripts complete before the next script runs?

                      Got put in twice
                      Dave Mason
                      [email protected]
                      Skype is dave.mason46

                      Comment


                        #12
                        Re: How to ensure succesively run scripts complete before the next script runs?

                        Paul,

                        This topic has been broached many times over the years on this forum.

                        Going along with Tom and the tips from Ira, Use a lot of udf's/functions if you need to run a bunch of operations at a time. As time goes along and records get more numerous, each step in an operation takes a little more time. When you add that to a user's very slow(in some cases) computer, it becomes a recipe for disaster.

                        In testing your daily update or any series of maintenance scripts/functions, suggest using a separate copy of the app, make sure there are lots of records(maybe a 100,000 or so), and hopefully done on an older/slower computer.

                        Going past all that, it can be done "Sometimes" with scripts, but you have to put something in the "master?" script like a wait for accompanied by a variable that gets changed in a called script. I never done this and won't do it. It is much simpler and more sure to create a function for that and then call each from a script or another function.

                        Also Look here http://msgboard.alphasoftware.com/al...to-continueing
                        Dave Mason
                        [email protected]
                        Skype is dave.mason46

                        Comment


                          #13
                          Re: How to ensure succesively run scripts complete before the next script runs?

                          Thanks Dave

                          Comment


                            #14
                            Re: How to ensure succesively run scripts complete before the next script runs?

                            Well, of the two suggested approaches I have only tried the function approach so far (no real scope to reduce the number of functions) and benchmarking it time-wise against the previous actionscript individual scripts approach (watching it run through (paint drying comes to mind)), the functions approach seems to have added a bit of time to the overall process. Of course this could be because it is now performing correctly, I don't know yet... To test this properly I am going to have to use three sets of output tables and compare the validity of the data after each test. This will take some time. I'll let you know how the script_play() approach fares tomorrow. Time for a beer now...
                            Paul

                            Comment

                            Working...
                            X