View RSS Feed

Development Team Blog

Why Some Files Are Not Migrated to the Latest VDF Revision

Rate this Entry
We try to make migration from any Visual DataFlex revision to the latest revision as smooth as possible for our developers, but one migration-related question has come up repeatedly in the forums: "Some of the files in my workspace didn't get migrated. What's going on?"

The migration wizard uses the same code parser that the Studio uses to determine what to migrate. As Sonny recently discussed in his blog Under the Hood: The Studio Parser, most source code files are not autonomous, meaning that they depend on other files for missing information. For example, a dbForm object in a source code file in a workspace depends on the dbForm class definition somewhere. Somewhere can mean the same file, but most likely means another file, either in the current workspace, the VDF packages or a library.

Just like the Studio, the migration wizard parses source code on a per-project basis. The reasoning behind this is that in order for a project to compile (without errors), all dependencies must be referenced in the project. The downside of this method is that if a file is not used in any project, migration will not migrate it.

We investigated creating some kind of workaround to allow migration of individual files without parsing, but this has a high potential of going wrong and introducing errors (bugs) in migrated code. The cardinal rule of any tool working with source code is that it must not break the code. So, like the Studio modelers who refuse to model components lacking information, we err on the side of caution.

The simplest way to ensure that all files that should be migrated are is to use a file/folder comparison (aka "diff") tool. I use Beyond Compare, but any utility that can compare file contents will do. You could, of course, do the migration and then compare it to the code in your source control repository. I have done this, too, but I prefer doing the full migration, getting everything just right, and then checking it into source control.

I recommend always migrating workspaces to a new location (the default setting). This makes it very simple to compare the "before" and "after" migration versions of the workspace and see exactly what has changed. You will see what files were migrated, what changes were made to each file and what files were not migrated. (The files that require migration will vary from revision to revision, see the VDF help topic "workspace migration" in the revision you are migrating to.)

So, let's look at a typical scenario:

You have migrated a workspace and are using your favorite diff tool to compare the "before" and "after" workspaces. You notice that some files that you expected to migrate did not. For the sake of this exercise, let's say one of the DD (Data Dictionary class) files was not migrated.

So, you open up the "before" workspace in the Studio and search for "Use {name of DD file}". The result shows that this DD is not used in any project, which explains why it was not migrated.

The simplest way to solve this is to:
1. Create a new project in the "before" workspace
2. "Use" the file(s) that were not migrated
3. Migrate the workspace again, but to a different "after" location (let's call it "after2")
4. Once the migration is complete, use your diff utility to compare the original "after" workspace to the new "after2" workspace
5. Copy the files that migration missed the first time from the "after2" to the original "after" workspace
6. Open the "after" workspace, now containing all migrated files, in the Studio for the new VDF revision
7. Compile and test
8. Check migrated source code into source control

This is a really straightforward way of solving this issue and the one we recommend.

I'll now address some questions that you may have regarding the above:

Q: How long will migration take?
A: It depends on the VDF revision you are migrating from and to, the complexity of your workspace, the size of your workspace and too many factors to even mention. If you are migrating a complex workspace from one major revision to the next, I would recommend setting aside a few hours to a day, plus whatever time you usually reserve for testing.

Q: I have a huge workspace that takes 2 hours to migrate each time I run migration, I don't want to do this repeatedly.
A: When migrating large workspaces, the most time consuming parts take place without intervention. Once you have answered the initial questions the wizard asks you, migration runs by itself. Even if this takes an hour or two, you are free to do whatever. Start the migration and go to lunch, read forum posts, or tell the boss you're hard at work.

Q: Migration's not that hard, I think I'll write my own migration utility.
A: To do migration right, meaning that it will work with any scenario, such as multiple levels of subclassing, libraries, determining which files should be migrated for each revision, etc. migration is a huge and complex job that is easily underestimated.


  1. Peter Crook's Avatar
    Sounds like a good way of cleaning up your Workspace. If a file isn't used why migrate it?

    Peter Crook
  2. Clive Richmond's Avatar
    Hi Dennis,

    You have migrated a workspace and are using your favorite diff tool to compare the "before" and "after" workspaces. You notice that some files that you expected to migrate did not. For the sake of this exercise, let's say one of the DD (Data Dictionary class) files was not migrated.
    I think this is wrong. The DDSrc is an integral part of VDF's framework and has a dedicate entry in the workspace file. In many ways it is similar to a library. So it should really be treated the same way as a library and migrated in full. As opposed to just those .DDs which happen to be collected when the contents of the AppSrc folder is parsed.

    For us migrating from 14.0 to 14.1 was time consuming until the penny dropped and we realised what was going on.

    Kind regards