Skip to content

What Actually Happens During Migration

The Workspace Migration Wizard uses the same foundational technology as the Studio to learn as much as possible about the workspace you are migrating. It does this by parsing the source code.

These are the steps taken during a migration – items in bold are those that may require interaction:

  1. Select the workspace to migrate
    This is done by double-clicking the workspace file (workspacename.ws) in Windows Explorer or using the Open Workspace option on the File Menu.

  2. Determine which revision of DataFlex is the host for the selected workspace
    This is important because there is a good chance that the workspace relies on the host environment (global subclass layer, additional build paths, etc.). If the selected workspace is not registered in any of the revisions of DataFlex installed on the machine running the wizard, you will have the option to run the migration in limited migration mode.

  3. Determine if there is a global subclass layer and/or library candidates
    If the default location was not used when creating the global subclass layer, and the system make path of the host revision was modified, you will have the chance to indicate where your global subclass layer resides.

  4. Determine the full scope of the development environment
    This is done by simulating the same make paths that the workspace would use in its host environment:

  5. Uses the paths in the existing .ws file.

  6. Uses the system make path defined for the host revision (when in full migration mode).

  7. Parse all the source files
    Found in the primary AppSrc and DDSrc paths to discover all files and sources used in the workspace.

  8. Identify projects within the workspace.

  9. Examine the web objects
    To detect which are published and which are not.

  10. In full migration mode:

  11. Examine the classes that would be used in the workspace's controls palette so that the class palette in the newly migrated workspace can be properly initialized.

  12. Examine the registry to find out whether non-standard classes are used in the host revision.

  13. Report all findings
    This is displayed in the Analysis Results tab.

  14. Select the target folders
    The suggested location will always use the configured Projects folder as the starting point for the new locations:

    • If you have a global subclass layer, it will be migrated into a library workspace with AppSrc set to the selected folder.
    • If you have extra paths in your system make path or the workspace's AppSrcPath (in the workspace file), they will be listed as library candidates. You can select to connect to an existing library (that was already migrated) or to copy those folders to a different location to be used by the migrated workspace in its AppSrcPath, or to keep them in the same location they are (they will be added to your AppSrcPath if not already there).
    • If other paths in the workspace’s .ws file point at directories outside the workspace structure, you will have a chance to opt on what to do with those paths: point to a different location, copy them to a different location, or not make any changes (i.e., use the current path in the .ws file).

  15. All the copying is performed.

    • If you are migrating the workspace in place, a backup copy of the current .ws file is generated.

  16. All paths in the workspace (.ws) file are adjusted to the new locations.

  17. If a global library is being created, workspace files (.ws and .sws) are generated for it.

  18. In full migration mode:

    • The DFC files are migrated – appropriate meta tags will be inserted in the respective source code files. Backup copies are made for any source files changed by this action.
    • The class palette is migrated – ClassList.xml file is created in AppSrc\Config folder.
    • DDData is migrated – DDClassList.xml file is created in DDSrc folder.
    • FlexCOM2 ActiveX control resource information formerly provided in separate resource (.res) files is serialized directly into the source file that uses the control. Backup copies are made for any source files changed by this action.
    • Published web methods in Web Objects (.WO files) are migrated to use meta-data tags instead of 'Send RegisterInterface' statements. Backup copies are made for any source files changed by this action.
    • The Client sizing option is applied to all dialogs – a backup of the files being changed is made, and the old size setting will still be in the source commented out.
    • Manifest files (*.exe.manifest) are updated to comply with Windows Vista requirements.
    • Source code in data dictionaries is updated - backup files of the changed DD files are made prior to the update.
    • The Studio Workspace (.sws) file for the workspace is created using relative paths.
    • In full migration mode, non-standard classes from the registry are migrated to the .sws file.

  19. Temporary files with the following extensions that are present in the migrated workspace are removed:

    • *.PRN
    • *.FLD
    • *.PBG
    • *.PKD
    • *.PRP
    • *.TRE
    • *.ERR
    • *.DSK
    • *.DBG

  20. Log files are output
    Summarizing the tasks performed during migration, errors that occurred during migration, warnings, and to-do items identified during migration.

See Also