Upgrading workspaces to a newer Visual DataFlex version

Upgrade pains

by Wil van Antwerpen

Upgrading workspaces

This is a subject that comes to revisit you at times and there are several ways in which you can tackle this little beastie. Ever since VDF8 there is a special wizard that helps you in migrating your applications from one version to another. However simple this event may seem for small projects, once your project is a little bigger you do want to plan this carefully. You do not want to give your end-users the typical "we added this and broke something else" experience that all too often happens. Does that sound familiar? Then have a look at the tips below.. If not, then you're the perfect developer and this doesn't count for you.

Decisions, decisions

Does the new version of Visual DataFlex warrant you to upgrade? No I'm not joking, this is a serious question. You can't just put your users on every new version unless you only have a few end users or the deployment of applications is under very tight control (for example when using Remote Desktop/Citrix )

There are several ways in which you can view this.

1. Bleeding edge, deploy beta software. Never do this unless you have an EXTREMELY good reason to do so. You can put your users in a world of hurt by doing this. Is that one feature really worth it?
2. Stay up to date all the time... (DAW loves you!) This seems like a very nice goal and is only feasible if you have a product that is in tight control deployment wise. If you have to deploy at a thousand locations then this isn't likely for you.. (you don't want to overload your support desk or do you?)
3. Stay one version behind.. This is a more traditional approach where you take the time for the product to evolve and for your development and Q&A teams to find the version specific flaws. This works fine for most products, but is less do-able with Visual Dataflex. Why? DAW does not have the habit of patching older versions -even while they claim to support it- so that's a downside of this approach. Instead they tell you to move over to the newer betterer version (with newer bugs too... DAW are you reading this? Do YOU want us to update more often so YOU can sell more client licenses? Then make this scheme work and port your patches into all supported versions!)
4. Switch on over when a good stable major version is released with enough new in there to make your users happy.

So for example switch from VDF 11.1 to VDF 14.0. This means you don't have to wait on your last version perse.. pretty soon for example you could change this from 11.1 to VDF14.1 if that fancies you more.

Suppose you already guessed what my favorite is? No? Correct, I'm on that last scheme, but don't let that stop you from following your own path. It works for me, that doesn't mean another upgrade scheme doesn't work for you.

Smooth upgrades

How can you make your upgrade easier to tackle? Well.. for starters, by migrating your workspace using the wizard -in each released version- to a new location you get to see how much work it will be. There's an overview screen that displays files included, files excluded and (drumroll..) warnings. That last one is your target. Open it and look at all of the problems the migration wizard found. Check them and see if they make sense. If they do make sense, the ** make the correction in the source workspace **. Yes you read that correctly by making your source workspace more compliant to the wizard, you make your life ALOT easier. When you've identified all of the problems (and made many changes to your source workspace) do check your changes into your version control code system of choice.

When you are done with removing the warnings.. don't finish the wizard (or delete the results) but instead rerun the wizard. Check that your edits have improved the migration wizards result.

Congratulations, you have now offloaded some upgrade pains to your current workspace and even if you do not get the chance to upgrade now (time constraints) your life will be easier the next time when you do get a chance. Not only this, but when you do start the actual migration, your codebase won't change that much, making it easier to track the upgrade changes.

Tips for speeding it all up

• The new studio is not always as smart as the older ones.. it is much more pernicky when it can't find something.

For example if you did not include all of the subclass definitions in your view, then the VDF12+ studio whines alot and can't draw your view in the designer. However if you open such a view in -say VDF10.1- then it draws perfectly. What gives? Well .. let's not go there and tell you instead that you can have the VDF10.1 Studio write out all those missing include files by just saving a space in the good ol' Studio.

• Move class definitions that ended up in your views and reports and put them in their own files. The studio doesn't like this type of construct. If you nested your class definition in your view, it is likely to cause your view not to be able to render itself in the designer.

External links

• Clean up your meta tags using the Cleanmarkers project over at VDF-Guidance

• Why doesn't that webapp work in the newer VDF.. Object required global.asa error