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

Suggestions on Installations

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

    Suggestions on Installations

    I am just around the corner from my first install. The application is written for a single department at a site. There may be as many as 16 different departments that want the application.

    My runtime license is for 10 users, but normally there will only be a max of 4 users per department/installation. By installing at the department level, my runtime license should be sufficient for the number of users per installation. It is a local server setting with pc's in the respective user's offices.

    My plan is to install using different sub-directories for each department i.e. g:\myapp\dept01 and g:\myapp\dept02.

    This could be 16 different installations for this one site.

    Is this the right way to go, or is there another way that could potentially save me time and/or effort when updates/upgrades start to happen?

    We are hoping for installation at 30-50 sites this next year so we're talking as many as 800 installs. Given this, even a small time saver will become very important.
    The installed base should double the following year.

    If you have any suggestions or hard lessons learned I would greatly appreciate hearing them.

    Thanks in advance,
    Jerry Gray
    FF&G, LLC

    #2
    RE: Suggestions on Installations

    Jerry:

    You have not provided enough information concerning the different departments at each site and how the information for each department differs.

    If the information for each department is the same except that it is department oriented. In other words, each department maintains information in the same format and same files with data that is unique to each department.
    If this is true, consider enhancing the file structures to include a department identifier that can be used to show only data belonging to that department. Then the application could be loaded once on each site. Login security would set access by department.
    This approach would require upgrading the run time to unlimited.
    This approach would reduce your maintenace needs. You would have to maintain one version of the application and distribute to fewer sites.

    Your approach opens the prospect of maintaining 50 to 80 different versions and distributing the updates on a very controlled basis.

    I hope this helps.

    bob adler


    Comment


      #3
      RE: Suggestions on Installations

      Bob,

      My original design included a department code which allowed for all users to access the same database. What I found was that each department is autononmous and sets their own policies/procedures/rules/regulations. Given this, I implemented routines and variables to allow them to customize the functions to meet their perceived needs.

      The funny part is that in the end, the data structure is identical, it's a matter of their own interpretation and implementation.

      This is a very large step as currently 98% of this is being done manually!

      We looked at the possibility of an "unlimited" license, but I think it will be cost prohibitive. We opted for the 10 user license with the ability to upgrade to whatever number we need. Breaking the installation down to the department level allows us to meet the need of the department and yet still stay within a reasonable licensing cost. The 10 user license will handle the current user base as they are managers within each department.

      The first site for installation has approximatley 4500 employees. When the full project scope is implemented, each employee will become a user. At that point I plan to have the application web based. That will mean a single WAS will suffice.

      What I'm looking for are ways to reduce the effort involved in updating the installations. For example, if I find a problem with a script for a single form, is there a way to zip that single script and email it to each user where they can install it or am I going to have to zip all of the forms and install them on each pc?

      Thanks for your response,
      Jerry Gray

      Comment


        #4
        RE: Suggestions on Installations

        Jerry:

        You will have to send the appropriate .ddd, .ddm and .ddx for forms or files as long as you have not changed the file structure. If the file structure is changed you will have to send the .cdx, .dbf and .fpt as well.

        If the script is part of the code controlled by the applications you will have to send .aLb, .alm and .alx. If you added a file the .Alb will have to be sent.

        The runtime versions will not permit users to make changes. It is your responibility to contole the updates.

        Look at setting version numbers that will help trigger the updates.

        I hope this helps.

        bob adler

        Comment


          #5
          RE: Suggestions on Installations

          Bob,

          Thanks for the input.

          I'm going to practice the different scenarios, using our notebook as the guinea pig.

          Jerry Gray

          Comment

          Working...
          X