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

Documentation / How-To - Missing Pieces

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

  • Documentation / How-To - Missing Pieces

    Here in my early stages of learning Alpha Five there appears to be very little information, both in the WIKI and the message boards (as far as my searches are concerned) in the following two areas -

    Toolbars - Specifically in their potential use as a menu for an application and generally in editing them other than customizing one by deleting existing pieces.

    Named Connection Strings - Documentation (What's new for Version 9) seems to state that you can change data sources by editing the connection string, but there is no example showing how, for example, to change between a local table (.dbf or .accdb) and SQL (whatever flavor). From the message boards it reads like you need to change every table, browse, etc. to change data sources. Which is it???

    Does anyone know of any good information on either of these subjects? Any help would be appreciated.
    - Bob
    BobT55
    Alpha Five Version 10.5 Build 4369 / Addins Build: 3712
    Active Link Tables via SQL Server 2008 R2 (on laptop)
    Win 7 Home Premium SP 1 - 64-bit
    Dell Inspiron 15 (N5110) i5 2410M 8 GB Ram

  • #2
    Re: Documentation / How-To - Missing Pieces

    Bob, there is a ton of information regarding Toolbars in the Local Help

    In case you heven't got it, here's the Wiki link.
    http://wiki.alphasoftware.com/How+to...Custom+Toolbar

    Connection strings are a little more complex.
    http://wiki.alphasoftware.com/Create...nection+String

    If this doesn't answer the question to your satisfaction, suggest you post a specific Q to a Forum of your choice.
    See our Hybrid Option here;
    https://hybridapps.example-software.com/


    There are 3 things you can do in any situation;
    Live with it, Change it or Walk away from it.

    Comment


    • #3
      Re: Documentation / How-To - Missing Pieces

      I too am recently new to Alpha5 and developing. Here's some useful information on what to understand when creating connection strings and the pitfalls of lessons learnt. Unfortunately I didn't get to Connection Strings 101, but I wish I did as it would have saved me some frustration in learning a useful lesson when creating connection strings.

      When creating connection strings uses a generic name. DO NOT USE words or text in the name of connection string that refer to the database or source because they can be misleading and create problems much later when you move from a test environment or staging environment to a live environment. If you fail to follow a generic naming convention what you end up with is a named connection string that isn't what it appears by its’ name and can confuse.

      Good naming convention: Isolation Procedures

      Poor naming convention: localhost MySQL Isolation Procedures

      The above poor naming convetion became misleading when I moved the staging area database from MySQL to SQLServer2008. The name didn’t reflect the data source and I had the choice of leaving the connection string name as is but changing the connection string. This changed what database my application was looking at and did the job but its’ name wasn’t appropriate. If I created another connection string with a name that represented my SQLServer datasource every grid and every lookup (and probably a few other things as well) would have to be changed. not a good choice.

      So when changing where web components look all that is required is to change the connection string from your staging area database to live database, so use a generic connection name.

      When you develop your database and transfer it to another database in the same database type or different database type (e.g. move from MySQL to SQLServer2008) all you have to do is change the string and all your grid data connections and Lookups will point to the new source.

      Comment


      • #4
        Re: Documentation / How-To - Missing Pieces

        My advice, name your connection string "conn" and never anything else unless you absolutely have to. Don't make the name have any significance because your situation will change, and then the name is confusing. If you ever have to merge two databases, if the connection string is named conn in both, then it is easy to merge the database AND the A5 web application. If they are different, then you have to forever live with at least two connection string names for the same application, or go through the labor of changing the connection string in one of your applications (a real chore).

        And since you will be typing your connection string value thousands of times as you build your application*, you want a name that is short, easy to remember and and means something. "Conn" means connection string, "Isolation Procedures" does not mean connection string, it means your application name.

        You should not name a connection string "Isolation Procedures", just name it "conn".

        There is an IADN Best Practices Guideline at http://alphadevnet.com/downloads/Alp...Guidelines.pdf.

        *Connection string is selected for grids, etc and typed in for xbasic and sql statements
        Steve Wood
        Join the ALPHA DEVELOPERS NETWORK
        There is no Cloud. It's just someone else's computer.
        Web - Mobile - Hosting - Products - Frameworks - Developer Resources
        AlphaToGo | IADN (100% Alpha Anywhere Websites)

        Comment


        • #5
          Re: Documentation / How-To - Missing Pieces

          Steve,

          In my case I use multiple connections strings. For my desktop active link tables app I use one (conn_data) to connect to the data source be it an Access database file or SQL and another (conn_settings) to connect to an Access table for local variables (user settings).

          My real question is how switching from "conn_data" (Access) to "conn_data" (SQL) would be managed as there seemed to be conflicting info on how the peocess is handled. Since the named connection string stays the same is it as easy as changing it to point to the alternate data source or are there further impacts (and manual changes) to be aware of?

          In Steve Workings message HERE it sounds like programmatically changing the string (keeping the name) is not currently possible and that lots of manual changes need to be made yet coming from Access I could dynamically repoint my linked tables on the fly. Not so in Alpha?

          Thanks for your help. I'll re-read your guide document again as a refresher!
          - Bob
          BobT55
          Alpha Five Version 10.5 Build 4369 / Addins Build: 3712
          Active Link Tables via SQL Server 2008 R2 (on laptop)
          Win 7 Home Premium SP 1 - 64-bit
          Dell Inspiron 15 (N5110) i5 2410M 8 GB Ram

          Comment


          • #6
            Re: Documentation / How-To - Missing Pieces

            Bob - let me clarify since you've linked another message into this.

            The current situation I have is that I've inherited an extensive application, mostly built-out and full of references to a single connection string.

            Now the customer is saying "I want multiple users and sites, and each will have their own data source." That's why I was wondering if I could "spoof" the existing named connection string to use variable data sources. I've decided that I cannot (and probably should not anyway).

            Had this application been designed to manage this multi-tenant, multi-database scenario from the beginning, it could have taken advantage of the relatively new A5 feature of Dynamic Connection Strings. The reason I cannot use them in this application is because they require the very specific naming convention, and I'm not about to try to find and replace every instance of the existing connection string with the new dynamic name.

            Lesson here is to think ahead about what your application may grow into, and be sure you keep the path as clear as possible for such expansions.
            -Steve
            sigpic

            Comment


            • #7
              Re: Documentation / How-To - Missing Pieces

              Now I'm going to reply to my own post, and raise the question especially to Steve Wood:

              I wonder if, in the interest of maintaining maximum flexibility and room for future growth, if it might be a good idea to always name a connection string as if it were a dynamic string, e.g. DynamicConnection_Conn.

              It still needs to be fed it's definition at startup time, but it really doesn't matter whether the definition gets changed at all after that. But, and here's the key: it could, and that is a potential barrier that is knocked down at the beginning.
              -Steve
              sigpic

              Comment


              • #8
                Re: Documentation / How-To - Missing Pieces

                I think that is a good idea for the reason you suggest if you can live with the limitations - ONLY for grids - not available for xbasic, Dialogs or reports. Personally I cannot live with that and would find another method.

                I wonder if you could somehow spoofed the connection string value in a5_application.ai at runtime (a5_application.ai is where the sql connection string alias is stored). I know that alias and connection string is put in memory but I don't know if each user gets a separate copy in memory when they first hit the website, or if there is only one copy of that alias and connection string in memory and everyone shares it.

                I also wonder if you can build separate instances of the web server and alter the connection string per instance. I don't see any option for that but it sounds plausable.

                Another (not so horrible) option is to create multiple a5_application.ai files and then totally duplicate your entire application for each client to login. You'd maintain one copy in Developer, and use File Watch to automatically update the other copies of the application when you publish a change. You can ensure their respective a5_application.ai files are not altered in the process.
                Steve Wood
                Join the ALPHA DEVELOPERS NETWORK
                There is no Cloud. It's just someone else's computer.
                Web - Mobile - Hosting - Products - Frameworks - Developer Resources
                AlphaToGo | IADN (100% Alpha Anywhere Websites)

                Comment

                Working...
                X