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

Recommended Upgrade Procedure Developer and Runtime

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

    Recommended Upgrade Procedure Developer and Runtime

    I purchased V11 yesterday.

    I already have V10.5, and have several applications running on Windows XP [I use Windows 7].

    When upgrading the Developer and Runtime. Do I uninstall 10.5 Developer on my PC, and Run-Time on users PCs first?

    In short, what is the recommended procedure for upgrading Developer and Run-Time from V10.5 to V11?

    Also, is the procedure the same, in V11, for updating applications after I've made changes? Right now I copy and overwrite all files except: asx, cdx, dbf, fpt, mpx, and muf.
    Carl C. Smith, Jr.

    #2
    Re: Recommended Upgrade Procedure Developer and Runtime

    V11 is a new version, not technically an upgrade from/to V10/10.5. You can install and run V11 independently and that might be your best choice until you have fully tested operation under V11.

    Make a separate directory for the application, copy it there, and try it out with V11 (developer).
    There can be only one.

    Comment


      #3
      Re: Recommended Upgrade Procedure Developer and Runtime

      Originally posted by Stan Mathews View Post
      V11 is a new version, not technically an upgrade from/to V10/10.5. You can install and run V11 independently and that might be your best choice until you have fully tested operation under V11.

      Make a separate directory for the application, copy it there, and try it out with V11 (developer).
      Thanks for the suggestion. When I do go from V10.5 to V11 It sounds like I should uninstall then install?
      Carl C. Smith, Jr.

      Comment


        #4
        Re: Recommended Upgrade Procedure Developer and Runtime

        For the runtime that would probably be best. Shouldn't really make a difference either way.
        There can be only one.

        Comment


          #5
          Re: Recommended Upgrade Procedure Developer and Runtime

          I have 10.5 and 11 on my PC. Absolutely no problems as a result of this thus far. (Just make sure you duplicate your data/code FIRST and don't "criss-cross.")
          (The v10.5 stuff is what I am presently still running "live" for my business. ~ A little online web-app for customers.)
          I think this is paramount: Once you open a "workspace" in v.11, NEVER go back & re-open it in v.10x.
          (Copy/duplicate the workspace directories first, so you have two "isolated" versions.) ~ To do otherwise is probably asking for trouble!

          Note: I'm referring to developing here. (I do not have the runtimes installed.)
          Last edited by SNusa; 02-01-2013, 10:43 AM.
          Robert T. ~ "I enjoy manipulating data... just not my data."
          It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
          RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

          Comment


            #6
            Re: Recommended Upgrade Procedure Developer and Runtime

            For a long time now, I have had v7, v8, v9, v10.5 on my developer machine. Only recently, I got rid of all but 10.5 and 11. I also had runtime for each. Moving forward, it takes the temptation away to go backward.

            You are right about never going back. I do mine by folder naming like: upsv10 copied to ups11. Once done I don't open the wrong adb with the wrong version(most of the time).
            Dave Mason
            [email protected]
            Skype is dave.mason46

            Comment


              #7
              Re: Recommended Upgrade Procedure Developer and Runtime

              Originally posted by DaveM View Post
              For a long time now, I have had v7, v8, v9, v10.5 on my developer machine. Only recently, I got rid of all but 10.5 and 11. I also had runtime for each. Moving forward, it takes the temptation away to go backward.

              You are right about never going back. I do mine by folder naming like: upsv10 copied to ups11. Once done I don't open the wrong adb with the wrong version(most of the time).
              Thanks to DaveM and SNusa for suggestions. I will definitely put applications in separate folders.

              Concerning my other question: "Is the procedure the same, in V11, for updating applications after I've made changes? Right now I copy and overwrite all files except: asx, cdx, dbf, fpt, mpx, and muf." Any thoughts?
              Carl C. Smith, Jr.

              Comment


                #8
                Re: Recommended Upgrade Procedure Developer and Runtime

                Carl, you might check the help system for information on "Alpha File Types". You'll see that reports for example are stored in the dictionaries for the table (or the set) upon which each report is based. This means that if you update a report layout for a customer you could send her your dictionary files for the table or set where the modified report is stored. This works well unless your customer is ALSO making changes to her reports. In that case if she copies your dictionaries they'll overwrite hers, wiping out any custom changes she may have made. Notice also that the same dictionaries (for the table or set) are used to store other objects, like forms, saved operations, etc. Any changes by the end user to these other objects will also be lost if you overwrite her dictionaries with yours.

                Also, you can "export" your report layout using the right click (context) menu on a report name in the Alpha Five control panel. The exported file could be sent to the customer and could then be "imported".

                So instead of replacing your entire application like you are now doing, you have at least two other ways to do upgrade a client's application. The key, and this is fundamental, is to understand where the objects in your application are stored. So study the Alpha Five "file types" section in the helps carefully.

                Comment


                  #9
                  Re: Recommended Upgrade Procedure Developer and Runtime

                  Along with Tom's excellent advice, May I say? If you never give a user the rights and abilities to alter or make their own stuff, then overwrite(except dbf and ftp) is a good thing to redo the app.
                  It is generally referred to as KISS. "Keep It Simple for Stupid" Not to imply anyone is stupid.
                  Dave Mason
                  [email protected]
                  Skype is dave.mason46

                  Comment


                    #10
                    Re: Recommended Upgrade Procedure Developer and Runtime

                    To add to Dave's advice, I don't allow my customer to change the application (well, most customers) so I ALWAYS send a complete application update. There were just too many times in days past when I sent only the files I thought were needed then discoverd that I forgot about some other change(s) and had to send and update to the update. That's embarassing and I don't do it anymore.

                    If you do have a customer that makes changes, you can use the Object_Import/Export scripts created years ago by Jim Chapman (I believe it was Jim) to transmit one script, function, menu, toolbar, layout, or operation at a time. I think those scripts are still in the Code Archive somewhere.

                    Comment


                      #11
                      Re: Recommended Upgrade Procedure Developer and Runtime

                      Thanks to everyone for their help and suggestions. For the time being, I've installed V11 along side V10.5. So far my applications seem to work well with V11. I've uninstalled runtime 10.5 from a test machine and installed 11 runtime. So far so good.

                      My applications run on the LAN, here in the plant. So I don't have to worry about sending to customers. I use profiles, set up in SyncBack [http://www.2brightsparks.com/syncback/], to download the needed files to folders on the file server [After making sure everyone is logged out]. It's worked well with V10.5, so should work well with V11.

                      Thanks again for everyone's help. I'm an electrical engineer by training, and would not have been able to put my applications together without help from 'real' developer's.
                      Carl C. Smith, Jr.

                      Comment


                        #12
                        Re: Recommended Upgrade Procedure Developer and Runtime

                        SyncBack - I've seen and used that tool. It was marketed under several names years ago. (It was even a freebie at one point.) ~ Second Copy (by Centered Systems) is another similar & excellent choice to synchronize & backup anywhere/everywhere. (also inexpensive, but not free)
                        Robert T. ~ "I enjoy manipulating data... just not my data."
                        It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                        RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                        Comment

                        Working...
                        X