Upgrading workspaces to a newer Visual DataFlex version: Difference between revisions
From DataFlex Wiki
Jump to navigationJump to search
mNo edit summary |
|||
| (21 intermediate revisions by 4 users not shown) | |||
| Line 3: | Line 3: | ||
==== Upgrading workspaces ==== | ==== 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. | 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. | 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 probably the perfect developer and this doesn't count for you.. do go read about some cool tricks at the [https://www.reddit.com/r/dataflex DataFlex reddit] instead. | |||
==== Decisions, decisions ==== | ==== Decisions, decisions ==== | ||
| Line 11: | Line 15: | ||
# 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? | # 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? | ||
# 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?) | # 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?) | ||
# 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 | # 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 is not a bad choice, but beware of one thing. 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!) | ||
# Switch on over when a good stable major version is released with enough new in there to make your users happy. | # 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 per definition.. pretty soon for example you could change this from 11.1 to VDF14.1 if that fancies you more. | ||
So for example switch from VDF 11.1 to VDF 14.0. This means you don't have to wait on your last version | |||
Even if you deploy on an older version, I still recommend to make your code ready to work with the latest DataFlex version. This allows you to test with the latest version while you still deploy on a familiar base. Once you do move over, there will be less changes in your code and it will be easier to manage the upgrades. | |||
Note that it is rarely a good idea to get behind too far as then the upgrades become more work and you will get larger changes in your application just for getting up to date. | |||
==== Smooth upgrades ==== | ==== Smooth upgrades ==== | ||
| Line 22: | Line 27: | ||
Check them and see if they make sense. If they do make sense, then '''make the correction in the source workspace'''. | Check them and see if they make sense. If they do make sense, then '''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. | 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'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. | 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. | ||
''' Rinse repeat ''' Rerun the wizard as many times as you need to bring the number of warnings down to a number that satisfies your goal. | ''' Rinse repeat ''' Rerun the wizard as many times as you need to bring the number of warnings down to a number that satisfies your goal. | ||
| Line 30: | Line 36: | ||
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. | 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. | 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. | ||
(*) If you do not use a version control system yet, then do yourself a real pleasure and use file comparison software to make sure that there are no unintended edits! Better even, go get yourself on [[Version Control]] now! | |||
==== Tips for speeding it all up ==== | ==== 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. | * 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 (as long as its pre vdf12)- 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. Another benefit is that other parts of the source gets updated as well ( Think of things like dropping the self syntax for objects, for example: Set Server to (OrderHea(self)) --> Set Server To OrderHea ) | ||
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. | * 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. | ||
* Use the latest migration wizard you can get your hands on. The VDF14.1 wizard will catch more as the VDF14.0 one. Even if you are eventually going to migrate to VDF14.0, use the one from 14.1 for refining your code. | |||
==== Troubleshooting ==== | |||
* The AppHtml folder is not included in my migration | |||
Is the folder physically inside your project structure? Is it in your workspace? | |||
* The datadictionary files are not migrated and changed into the new syntax. | |||
Are all your DD classes registered in DDClassList.xml? | |||
==== External links ==== | ==== External links ==== | ||
* Clean up your | * Clean up your code using [https://projects.vdf-guidance.com/projects/dfrefactor dfRefactor] project over at [http://www.vdf-guidance.com VDF-Guidance] | ||
* Why doesn't that webapp work in the newer VDF.. [[Object required global.asa error]] | * Why doesn't that webapp work in the newer VDF.. [[Object required global.asa error]] | ||
* Data Access KB article [http://www.dataaccess.com/kbasepublic/KBPrint.asp?ArticleID=2400 INFO: Why did some of my files not get migrated (when upgrading to VDF 12 and higher)? ] | |||
* Data Access online help - [https://docs.dataaccess.com/dataflexhelp/#t=mergedProjects%2FTools%2FWorkspaceMigrationWizard_pnl_WelcomePage.htm Studio Workspace Migration] | |||
[[Category:How To]] | |||
[[Category:Tutorials]] | |||
[[Category:Studio]] | |||
Latest revision as of 13:45, 24 December 2021
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 probably the perfect developer and this doesn't count for you.. do go read about some cool tricks at the DataFlex reddit instead.
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.
- 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?
- 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?)
- 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 is not a bad choice, but beware of one thing. 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!)
- 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 per definition.. pretty soon for example you could change this from 11.1 to VDF14.1 if that fancies you more.
Even if you deploy on an older version, I still recommend to make your code ready to work with the latest DataFlex version. This allows you to test with the latest version while you still deploy on a familiar base. Once you do move over, there will be less changes in your code and it will be easier to manage the upgrades.
Note that it is rarely a good idea to get behind too far as then the upgrades become more work and you will get larger changes in your application just for getting up to date.
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, then 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.
Rinse repeat Rerun the wizard as many times as you need to bring the number of warnings down to a number that satisfies your goal.
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.
(*) If you do not use a version control system yet, then do yourself a real pleasure and use file comparison software to make sure that there are no unintended edits! Better even, go get yourself on Version Control now!
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 (as long as its pre vdf12)- 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. Another benefit is that other parts of the source gets updated as well ( Think of things like dropping the self syntax for objects, for example: Set Server to (OrderHea(self)) --> Set Server To OrderHea )
- 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.
- Use the latest migration wizard you can get your hands on. The VDF14.1 wizard will catch more as the VDF14.0 one. Even if you are eventually going to migrate to VDF14.0, use the one from 14.1 for refining your code.
Troubleshooting
- The AppHtml folder is not included in my migration
Is the folder physically inside your project structure? Is it in your workspace?
- The datadictionary files are not migrated and changed into the new syntax.
Are all your DD classes registered in DDClassList.xml?
External links
- Clean up your code using dfRefactor project over at VDF-Guidance
- Why doesn't that webapp work in the newer VDF.. Object required global.asa error
- Data Access KB article INFO: Why did some of my files not get migrated (when upgrading to VDF 12 and higher)?
- Data Access online help - Studio Workspace Migration
