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



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

User App Version Updates

  • Filter
  • Time
  • Show
Clear All
new posts

    User App Version Updates

    I have an interesting twist on the need for backup/restore. I hope someone will point me to a "that's nothing new, here ya go" location.

    After providing my users with a version of my application, I would like to be able to provide them the next version while maintaining their existing data.

    There would be no changes in the DBF structures but likely changes in the scripts, forms and in-line basic.

    If they backup everything then install a new version into the same directory, will restoring everything revert back to the previous version forms, etc?

    Is there a way to list previous backups for the user to choose which one to restore?

    I would like to provide the user a way to do these things from a form that I call up within the application maintenance screen.


    Thank you,


    Re: User App Version Updates

    Gene here.

    I found a partial answer. Just create a new version without the DBF files. That would seem to work for an upgrade.

    So, my only remaining question has to do with my desire to provide the user with a non-geek (if you will) interface for backing up and restoring their own data.
    Having them select specific files to do so would require them to have knowledge of Alpha which seems to me to be unreasonable. Any Xbasic based approaches to this that
    would list their existing backups to choose from?



      Re: User App Version Updates

      I do this all the time (issue updates that is) but the only reason someone should want to go back to a previous version is if your update blew up their application. At least that is my thinking and the way all my customers think.

      The things to consider is if you do version updates, you may want to configure the updates where they have to step through them if the updates include things such as adding fields to tables.
      Example would be not letting someone with version 1 update to version 3 without updating to version 2 first. If you do not do this and you've added fields in tables over time then the overhead to check all the tables that have changed between version 1 and say version 10 could be huge.

      This should explain what files to include in your updates.

      The way I do it is I create an update, compile it into a .exe file using a install creator software. I set the update to check the version they have and if allowed, proceed. Then it automatically backs up their existing app and all data files as well, creates a folder and stores the backup in it. Then it applies the update. If by some chance the update destroys there application it is just a simple matter of coping the backup files back into the application directory.

      There are a lot of ways to tackle this. Just depends on what you want to do.


        Re: User App Version Updates

        DITTO preston
        with a small twist. When dong datafiles that changed like adding a field or 2
        My installer creates the backup folder where planned
        new data tables are installed with no data.
        The twist: I use a bootstrap to append data from the backup to the new tables and then the app restarts without the bootstrap adb.
        Small apps may do another way, but this has served me well since version 5 or so.
        Dave Mason
        [email protected]
        Skype is dave.mason46


          Re: User App Version Updates

          Originally posted by DaveM;701335
          The twist:[/B] I use a bootstrap to append data from the backup to the new tables and then the app restarts without the bootstrap adb.
          Small apps may do another way, but this has served me well since version 5 or so.
          Doesn't that tag it as a shadow?


            Re: User App Version Updates


            If you are planning to overwrite all the client's files EXCEPT for their data, beware of a problem that can crop up if they're using Alpha's security features to organize their people into users, groups, and use password logins. Their users, groups and logins are not stored in their "data" and will be overwritten by your files. For purposes of this post "data" means DBF, FPT and CDX files.


              Re: User App Version Updates

              You guys all talk somewhat above my pay grade. Thanks for elevating my knowledge level.

              Tom, My application does not use Alpha's security features so that does not appear to be an issue. You do mention that the data files include DBF, FPT and CDX files. Should I remove all these files from the directory from which I build to result in overwriting all the clients' files EXCEPT for their data? Also, should this removal be done BEFORE or AFTER creating an AEX file? I suspect before but do not know if the resulting installation will work if I do.

              Preston, I see your point and my thoughts are to install a full version whenever/if I change the DBF structure and updates to that version which will not include and DBF files. I am using a build software bu the name of Advanced Installer and am just using it for the first time (several successful builds done). I like what you describe regarding backup/restore functions within the build software. I need to become familiar with this in Advanced Installer.

              Thanks to you two for your help.



                Re: User App Version Updates


                I have only limited experience building or updating the AEX file. Would be surprised if the 'data' files get stored there. However, this is easy to test, especially if you have arranged for your database files to live in a single folder. You can copy your development database folder to another location. Once there, make a few changes to the 'data' in the second location. Then make changes and updates on your development files, and practice "installing" them on the files in that 'second' location. Doing this is something you should be doing anyway, I'd argue. This technique will let you see if data in the 'second' location is changed when you do the update, and will permit you to confirm that the update you're saving has actually been installed.


                  Re: User App Version Updates


                  I use Actual Installer. I am not familiar with Advanced Installer.

                  In Actual Installer I use this command, set to fire At Folder Select Dialog. During an update the user cannot select the folder as the installer reads where the app was installed but I fire the command at that dialog as I use variables in the command.
                  <SystemDir>\cmd.exe /C xcopy <InstallDir> <InstallDir>\Before517 /I /Y /Z
                  This command tells the installer to run cmd.exe, fire xcopy, create a directory named "Before517" in the application's main directory and then copy the contents of the application directory to the new directory. If that makes sense.

                  As for what the file types are and what they are used for, see:

                  I build an AEX file all the time in my applications. It basically stores the information that is in the .adb file but in encrypted format. So if my app was "appname.adb" then the AEX file created would be "appname.AEX"
                  When Alpha starts if the appname.AEX file is present it will load it as well as the appname.adb. So why even make an AEX file since they both contain the same info?

                  The main reason to create an AEX file is to encrypt the scripts and functions in the .adb file so you can remove them from the .adb file. This keeps prying eyes from loading you app using the Alpha developer and trying to see what you did in the scripts and functions but at the same time keeping all of those available for your app to use.

                  For each app I develop I use two directories. One contains all the files for the app that I use while developing it. The other is a distribution directory. It contains an exact copy of the development folder except I create the AEX file and then remove all scripts and functions from the the .adb file. Just make sure you create the AEX file before you remove the scripts and functions from the .adb file. While I do password protect all my scripts and functions, plus use the "OPTION Encrypted_tokens" statement in all of them, creating the AEX file adds another layer of hacking protection. Just make sure you never remove any scripts or functions from your development .adb file or you will be sunk if you need to change any existing scripts or functions.

                  So, if an AEX file exist, Alpha will load it. Alpha will then look in the .adb file for scripts and functions and if any exist Alpha will use them. If they do not exist in the .adb file then Alpha will look in the AEX file for them.


                    Re: User App Version Updates

                    I send updates daily. Usually they are zipped where the knowledgeable clients unzip in a clean folder and copy to the production folder.

                    I do not send dfb, ftp or cdx files. The first 2 have data and the cdx is the indexes for the dbf files.

                    So, theoretically, all the other files are changeable. I DO send in a package like: if I have only done work to the code, I will only send the .adb and associated files. If I change a form, I will send the support files for that form whether it be dbf or a set. Sets, I send the whole set.

                    User is to compact the works space after download and copy.

                    The installer I use and the ones mentioned above basically just zip the files into an exe and deploy for you, but they can have other tools built in as well.
                    Dave Mason
                    [email protected]
                    Skype is dave.mason46


                      Re: User App Version Updates

                      Hi Preston.

                      Taking this one chunck at a time.




                        Re: User App Version Updates


                        You mention that if you change a form you send along the related DBF files and sets. This implies that not sending the DBF, FPT and CDX files when there are form changes will not work. Am I understanding that correctly?

                        I would like for the users to be able to backup/restore their data files only without having access to the control panel. Is that possible?



                          Re: User App Version Updates

                          The dbf, fpt, and cdx holds data. No reason to send those. a report/form/ other do not reside there. So, all the other files are sent instead.
                          for a set
                          ( Sets hold no data at all)
                          zip them and send or put them in an installer and send

                          If you change a dbf file, it is different.

                          Did I clarify enough

                          small zip files or similar, I just email. Large files are placed in a folder on a website and I just send a link to them in an email.
                          like: fttp://
                          Dave Mason
                          [email protected]
                          Skype is dave.mason46


                            Re: User App Version Updates

                            Thank you Dave.

                            I have added a 'Backup' button to my user utilities form that only backs up their data files (DBF, FPT, CDX). My plan is to instruct them to create a backup using this utility, install the update which includes everything, then restore their backup file. I have yet to try that to confirm. Am in the process.



                              Re: User App Version Updates

                              Originally posted by Gene FitzPatrick View Post
                              Thank you Dave.

                              I have added a 'Backup' button to my user utilities form that only backs up their data files (DBF, FPT, CDX). My plan is to instruct them to create a backup using this utility, install the update which includes everything, then restore their backup file. I have yet to try that to confirm. Am in the process.


                              If I am reading this right then they will be right back to where they started before any update and without the update.