This process is non-destructive of your existing application (but make a fresh back up just in case). We will copy your existing project in to a fresh empty Framework project.


Initial Steps

    1. Download the current version of the Framework and extract the files to a new location.
    2. Make a backup of your current application. Do your work on the copy, not your original.
    3. Make a backup of your current database before any migration steps.

Make a new empty Framework project

    1. Using the latest version of the Framework, use the Copy Project utility to make a fresh Framework-based project which will hold your migrated project.
    2. Include the steps to create a new database for the new Framework project, set your new Framework project to target that new database.
    3. The Framework has one User Defined Function named errorout (see here if the code is needed). Be sure to reproduce this in the new project. If you are familiar with Xbasic Modules, you can move the errorout function to that area.
    4. Publish and test this new Framework project. When you publish, check the box to 'Compile functions in to an AEX file' (assuming you did not move the errorout function to an Xbasic Module).
    5. Go through the relevant tasks in Getting Started to set up your new Framework-based project.

Merge in your existing project

    1. Using the list of Framework files that match your existing application (see Reference), determine if you made any changes to the Framework that need to be reproduced in the new update. Make a note of all important changes.
    2. As you go forward, it may help to have the existing application open and the new Framework-based application open at the same time. Compare pages, for example, compare the About.A5W from both existing application and the new Framework project.
    3. Copy the non-Framework files from your existing application in to the new Framework project folder. If any files already exist, DO NOT overwrite them. Instead, evaluate why the file already exists and make appropriate changes to the Framework file rather than overwriting.
      1. Option - you can opt to move files one at a time, or one module at a time. If for example you have a Store; move in just the Store-related A5W pages, components, security settings, etc. This methodical method allows you to fully migrate and test one module at a time.
      2. Recognize, as you migrate older A5W pages you might (depending on what Framework version you are migrating from) have to update the user defined function names, the parameters for any a5w_include("pagename") and perform some layout modifications.
      3. You may also need to make changes that are independent of any Framework issue if you are also moving from an older version of Alpha Five/Anywhere.

Recreate any User Defined Functions

    1. Your existing application may have user defined functions that need to be recreated in the new project.
    2. The Framework deploys one User Defined Function, named errorout (see here if needed). Be sure to reproduce this in the new project.
    3. Newer versions of Alpha Anywhere might also have code entries for Node, Xbasic Modules or Classes, etc.


Database Updates

    1. The database for each version of the Framework is slightly different. You can find the schema for the current version here.
    2. Each developer has a different method and tools to manage their database, but the basic task is to ensure your live database schema matches the current Framework version.
    3. Here are some suggested methods:
      • Manually compare the current schema to your live database and manually make each modification.
      • Use a tool such as Navicat to "compare" your current schema to the current Framework schema, and then update your schema to match.

Publish the new project

    1. Publish your migrated project for testing. Be sure your initial publication goes to an empty folder rather than over any existing files. DO NOT publish directly to a live location (we don't trust our migration process to be that perfect!)
    2. Note - sometimes Alpha fails to publish some files or subfolders, check to make sure.
    3. As above, when publishing, check the box to 'Compile functions in to an AEX file' (at least once during the migration process).
    4. Be sure to specifically publish the new wt4.aex file.
    5. It is also good policy to restart your Alpha Application Server after publishing.


    1. Congratulations, your newly merged project should be ready to use. Once you are sure, take the required steps to replace your live application and database with your new build.


Errorout function:


FUNCTION errorout AS C (errormsg AS C = "", severity AS N = 0 )

       fldr = "\a5\logs"

       logfile = fldr + "\sql_error.log"

       if file.exists(fldr) = .f.

               file.dir_create_recurse(fldr)

       end if

       vErrorMsg = time("yyyy/MM/dd 0h:0m:0s") + "|" + ErrorMsg + crlf() + replicate("-",10) + crlf()

       file.append_line(logfile,vErrorMsg)        

       if severity > 4

'                email or SMS code here to send a notice to an Admin

       end if

END FUNCTION