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

Best practice for storing global server variables

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

  • Best practice for storing global server variables

    Is there a built-in configuration file for maintaining global variables that live in server memory for the lifetime of the app server? The only time they would need to be reloaded is when the app server is restarted. Here is an example of some of the types of variables I am describing:

    1. Various subdirectory paths for storing images and what not.
    2. Local task server names.
    3. Web and RESTful service URI’s.

    I would rather not store these variables in the web project profile and have to re-publish if I ever need to add or change these variables. I would prefer to change the variable information in some kind of config file that resides on the web server and then restart the web server to reload the new variables.

    What is the best practice in Alpha for storing server variables in memory so the app server is not constantly reading a config file after every client request? The closest thing I have seen is the Application Server configuration file which is named “ServerConfig.xml”. However, I have been told not to mess with this file even though the documentation says it can be used for this purpose.

    Thanks

  • #2
    Re: Best practice for storing global server variables

    I do remember seeing a 'server variables' in alpha. This may be an option...however, I would do something custom
    You have 2 options:

    Use mysql and create a system_setting table (Our preferred)
    systemsetting.png
    -Advantages: Does not require a server restart (only a logout/login if implemented in the way below), System settings can be easily editable if needed, from the application (using an alpha grid component)

    Use a file on the server c:/myconfig.txt Or whatever
    The c:/myconfig.txt can be formatted however you like, the easiest is probably newline seperated name value pairs
    setting1=value
    setting2=value2
    setting3=5
    setting4="C:/image_storage_path"

    When the user logs in, redirect to a post_login_process.a5w (set this up in websecurity - set the page after login to post_login_process.a5w)

    post_login_process.a5w (This shows the MySQL Example - to read from the file you would use file.open(), while (.NOT. file.eof()) and dim line as C=file.readline() - then you would split line on = , the left would be your variable name, the right would be your variable value and then you can store it in session.
    Code:
    'Note: It would probably be more efficient to call conn.open() and a conn.execute as opposed to calling 5-6 sql_lookups.
    'Another option is to call conn.open() and call sql_lookup(conn,.....           - I dont think this opens new connections everytime it is called then. - youd have to look at mysql query logs to see.
    
    if eval_valid("session.batch_build_directory")==.f. then
        'load the batch build directory
        session.batch_build_directory=convert_type(sql_lookup("::name::conn","system_setting","system_setting='BATCH_BUILD_DIRECTORY'","setting_value"),"C")
    end if 
    
    if eval_valid("session.contact_name")==.f. then
        session.contact_name=convert_type(sql_lookup("::name::conn","system_setting","system_setting='CONTACT_NAME'","setting_value"),"C")
    end if 
    response.redirect("index.a5w")
    end
    Scott Moniz - Computer Programmer/Analyst
    REA Inc.
    http://reainc.net
    (416)-533-3777
    [email protected]

    REA INC offers consulting services, programming services, systems design, database design, third party payment gateway integration (CHASE, PAYPAL, AUTHORIZE.NET) and developer support.
    If you need custom code, or 1-to-1 mentoring in any facet of your database/web application design,
    contact us to discuss options.

    Comment


    • #3
      Re: Best practice for storing global server variables

      Thank you Scott.

      So after the user logs in, you redirect to an interim post login page which loads your configuration settings into session variables and then you redirect to the starting page of your application? This sounds like a good option.

      I was looking closer at "application variables" which are stored in the web project profile and "application global variables" which are stored in the web project properties. Both of these variable types are stored in the a5_application.a5i file. This may not be a bad option either if its okay to just re-publish the a5_application.a5i file after making changes to your settings and not having to re-publish a bunch of other system files. This probably requires a server restart, so there are definitely advantages to your technique assuming the settings changes are not significant enough to require users to have to log out anyway. Your technique also allows you to make settings changes through the web application which is a big advantage.

      Comment


      • #4
        Re: Best practice for storing global server variables

        So after the user logs in, you redirect to an interim post login page which loads your configuration settings into session variables and then you redirect to the starting page of your application? This sounds like a good option.- Correct

        I was looking closer at "application variables" which are stored in the web project profile and "application global variables" which are stored in the web project properties. Both of these variable types are stored in the a5_application.a5i file. This may not be a bad option either if its okay to just re-publish the a5_application.a5i file after making changes to your settings and not having to re-publish a bunch of other system files. This probably requires a server restart - Disadvantages: You are modifying alphas files (possible corruption etc), it DOES require a publish AND a server restart.

        so there are definitely advantages to your technique assuming the settings changes are not significant enough to require users to have to log out anyway. Your technique also allows you to make settings changes through the web application which is a big advantage. - Yep, through the web app is a big advantage. - For critical settings changes, you can also announce a maintenance shutdown to your users, stop the app server, change a setting, restart the app server (If you are making a critical system setting change). For a slight system change you can ask a user to logout/login. (In your logout page you should delete your session variables. delete session.batch_directory delete session.contact_name) - Also, the .a5i variables MAY be cached (not sure)
        Scott Moniz - Computer Programmer/Analyst
        REA Inc.
        http://reainc.net
        (416)-533-3777
        [email protected]

        REA INC offers consulting services, programming services, systems design, database design, third party payment gateway integration (CHASE, PAYPAL, AUTHORIZE.NET) and developer support.
        If you need custom code, or 1-to-1 mentoring in any facet of your database/web application design,
        contact us to discuss options.

        Comment


        • #5
          Re: Best practice for storing global server variables

          I did not know about deleting session variables in the logout page for a logout/login situation.

          Alpha handles the updating of the application variables in a5_application.a5i, so it should not get corrupted. However, any variables added to ServerConfig.xml is done outside of Alpha and could possibly get corrupted.

          Thanks.

          Comment


          • #6
            Re: Best practice for storing global server variables

            Well the issue is when you logout, the session variables MAY remain there. It is better to explicitly delete them.
            E.g in logout.a5w

            <%a5
            a5ws_logout_user()
            delete session.batch_directory
            delete session.contact_name
            %>

            Just because you call a5ws_logout_user() does not mean the batch directory and contact name variables are cleared. So next time you go to load it using
            if eval_valid("session.batch_directory")==.f. it will not refresh the variable because it already exists. By deleting it in logout, you will force the next call to reload the system setting variable.

            Of course you can get rid of eval_valid("session.batch_delivery") and just have the line
            session.batch_delivery=sql_lookup() 'blablabla

            Another option that just crossed my mind is to have a
            globals.a5w page - in it.
            We use this sometimes, and so do other applications (e.g Yii Framework in PHP has a config.php it reads from)

            dim batch_directory as C="c:/batch"
            dim contact_name as C="John Smith"

            On ALL pages of your application (or pages which require the variables):
            mypage.a5w
            <%a5
            a5w_include("globals.a5w")
            ?"Contact name is: "+contact_name
            %>

            This method would NOT require a server restart.
            Just an edit to globals.a5w and publish
            Scott Moniz - Computer Programmer/Analyst
            REA Inc.
            http://reainc.net
            (416)-533-3777
            [email protected]

            REA INC offers consulting services, programming services, systems design, database design, third party payment gateway integration (CHASE, PAYPAL, AUTHORIZE.NET) and developer support.
            If you need custom code, or 1-to-1 mentoring in any facet of your database/web application design,
            contact us to discuss options.

            Comment


            • #7
              Re: Best practice for storing global server variables

              Originally posted by DaveF View Post
              I did not know about deleting session variables in the logout page for a logout/login situation.

              Alpha handles the updating of the application variables in a5_application.a5i, so it should not get corrupted. However, any variables added to ServerConfig.xml is done outside of Alpha and could possibly get corrupted.

              Thanks.
              There is a risk of corruption if you edit the a5_application.a5i file manually (that is what I was referring to sorry).
              Scott Moniz - Computer Programmer/Analyst
              REA Inc.
              http://reainc.net
              (416)-533-3777
              [email protected]

              REA INC offers consulting services, programming services, systems design, database design, third party payment gateway integration (CHASE, PAYPAL, AUTHORIZE.NET) and developer support.
              If you need custom code, or 1-to-1 mentoring in any facet of your database/web application design,
              contact us to discuss options.

              Comment

              Working...
              X