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 publishing project with MySQL data source

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

    "best practice" for publishing project with MySQL data source

    Hi there,
    As with many of you, I am in the process of changing to MySQL from DBF.

    I have 2 environments:
    Development: my laptop, running mysql and A5v12
    Production: office server and mysql running on another server in our office data centre

    When developing my software, I use a localhost connection string with my own username and password I set up and it all works great. However, when I go to publish it to the server, I have to change the connection string to the office server.

    The problem I am running into is that I can't configure my development server to use the prod connection string because I can't access the prod server through the firewall. How do i configure the project to use the prod connection string when on the server, but my development string when I'm working? I don't have the development application installed on the server, so I don't really know how to even make the production connection string.

    Is there some way to detect the environment? or do I have to manually paste in the string before I publish??

    What are the best practices for this? What is everyone else doing?

    Thank-you!

    #2
    Re: "best practice" for publishing project with MySQL data source

    Create two profiles, configure one for localhost and one for your web server.
    When you are testing you can publish to localhost. Then choose to publish to the web server when you are ready.

    Getting through the firewall is a different issue. If you don't have permissions to remotely access the server, you will need to contact your network administrator.
    Alpha Anywhere v12.4.6.5.2 Build 8867-5691 IIS v10.0 on Windows Server 2019 Std in Hyper-V

    Comment


      #3
      Re: "best practice" for publishing project with MySQL data source

      Thanks for the reply, but I don't think you're quite getting my problem. This is not a publishing problem.. I can publish to the production web server easily. This is a data string problem.

      Dev data access = localhost, devuser, password
      Prod data access = mysql.company.com, produser, password

      My dev connection string works great on my machine, but won't work on the server, and the prod connection string will work on the server, but not on my dev machine due to permissions and firewalls.

      How do I tell A5 to use the prod connect string when running on the server, and the dev string when on my machine? If I try to configure the prod string on my machine before I publish it to the server, i get an error saying can't connect and won't let me save it.

      Doesn't someone else have this problem?? I can't be the only person using a proper production database server that isn't open to the internet.
      Last edited by whiteatom; 12-04-2013, 04:10 PM.

      Comment


        #4
        Re: "best practice" for publishing project with MySQL data source

        Sounds like you need to look at path alias in the Web Project Profiles and create a different path alias when publishing to the web server.

        Maybe someone else can offer better advice.
        Last edited by iRadiate; 12-04-2013, 04:19 PM.
        Alpha Anywhere v12.4.6.5.2 Build 8867-5691 IIS v10.0 on Windows Server 2019 Std in Hyper-V

        Comment


          #5
          Re: "best practice" for publishing project with MySQL data source

          hello

          take a look at not just path alias also connection string alias
          if you set it up properly then you don't have to change anything at all.
          on your local laptop it will connect properly and on the server it will refer to proper connection string.
          thanks for reading

          gandhi

          version 11 3381 - 4096
          mysql backend
          http://www.alphawebprogramming.blogspot.com
          [email protected]
          Skype:[email protected]
          1 914 924 5171

          Comment


            #6
            Re: "best practice" for publishing project with MySQL data source

            Originally posted by GGandhi View Post
            hello

            take a look at not just path alias also connection string alias
            if you set it up properly then you don't have to change anything at all.
            on your local laptop it will connect properly and on the server it will refer to proper connection string.
            Ok.. So you're saying set up the connection for each server with the same alias and it should work? If so, how do I set up a connection string on the server? the only place I can see to do it is in the development application - which is only on my computer, not the server. Is there some hidden option to set up SQL connection strings in the application server somewhere?

            thanks for your help!

            Comment


              #7
              Re: "best practice" for publishing project with MySQL data source

              PathAlias is DBF setting and has no impact on SQL connection string. Alpha has a built in method to resolve your dual-connection string issue.

              - Go to your server publishing profile and open the Named AlphaDAO Connection String window.
              - You will see the Connection Name and the Connection String values. Your's probably all say "(default value).
              - Select your server Profile Name, double-click the appropriate Connection String Name (you probably only have one).
              - Edit this to match your server login.

              Now you will have one Connection String for the localhost and a different one for the remote server.
              Steve Wood
              See my profile on IADN

              Comment


                #8
                Re: "best practice" for publishing project with MySQL data source

                Should you duplicate the connection string name for both localhost, and on your production server? How does a component utilizing a connection string know to use the correct named string on a remote server if you don't? (Since you choose the connection string at the component level) If I use a connection string named development that uses localhost, and a connection string named production that use the IP of my server as the host do I have to go to each component and change the name of the connection string before publishing? That wouldn't be practical.

                Is there a tutorial or video on this? Couldn't find anything that explains this in detail, or gives a good example. When I pull up the connection strings in the publishing profile both are present, from what I can understand the local host is set to default, and you set your production named string to the production named connection string settings by choosing it or rebuilding it from the dialog? this seems redundant, and I don't understand why you have to repeat this process. Guess I'm missing something? The help on this dialog is vague.

                A good example of a development localhost, connection string, vs a production host connection string, and switching between the 2 within a webproject would go a long way.

                Thanks,
                Bob

                Comment


                  #9
                  Re: "best practice" for publishing project with MySQL data source

                  http://www.alphasoftware.com/blog/co...remote-server/ I did find this

                  Comment


                    #10
                    Re: "best practice" for publishing project with MySQL data source

                    This is not working. After going through the blog article, that explains that you can simply change the profile of the named connection string definition in the local webroot publishing profile (in the Edit named connection strings builder).

                    The way I understand it Alpha then publishes the substituted connection string that allows you to use the same named connection string for both development, and remote server, this then allows you to use the same named connection string for your web components, and have them work on your development machine, using a local database, and on your production server using a production database.

                    What file is the connection string set in within the files to be publish? Is it encrypted within the local development files? Can it be manually set there since it is encrypted once published? It seems to me that the builder is not working properly.

                    No matter what I try I cannot get the correct connection string to publish on my server. I get this error in my browser: The SQL API you requested is not installed

                    Comment


                      #11
                      Re: "best practice" for publishing project with MySQL data source

                      Somehow I was able to finally get 2 different connection strings into the a5_application file. This is something that would seem to be very simple, like you don't need a builder with a default setting. It should be connections strings that will be published on your server: Name and String. the whole default thing is very confusing, and the builder is bug infested, either that or something is corrupted on my copy of the developer. Since this is such a common practice it seems to me that there should be a much simpler way to organize your connection strings for development and production. GOOD GRIEF!!!!

                      Comment


                        #12
                        Re: "best practice" for publishing project with MySQL data source

                        The Gurus are silent ('Crickets')
                        Last edited by bob9145; 07-11-2015, 02:56 AM.

                        Comment


                          #13
                          Re: "best practice" for publishing project with MySQL data source

                          I avoid this by simply testing live. I use security so that only I can view the test component. This seems to work without complication.
                          This also allows me to add another user to the testing group if I want to at any time. I like to eliminate as much concern about local vs production as I see it as a waste of time.
                          NWCOPRO: Nuisance Wildlife Control Software My Application: http://www.nwcopro.com "Without forgetting, we would have no memory at all...now what was I saying?"

                          Comment


                            #14
                            Re: "best practice" for publishing project with MySQL data source

                            Thank you Charles, that makes sense. I just think the concept of the builder complicates what connection strings are published. At one point I created 2 connections strings with the same name one for development localhost, and one for production, that sent the builder into a nose dive. Since the connection string once published is encrypted it can be confusing. I eventually (from the AlphaDAO Connections dialog) changed the local webroot connection string to the string I wanted to publish to the server. This actually worked. Probably because I was compensating for crashing the builder with the dual named connection string. I have the string I want publishing, and am afraid to touch the settings, staying out of that rabbit hole for now.

                            Comment

                            Working...
                            X