Part One: Preparing Your Application
I don't know why exactly, but somebody coined the term "migration" to describe the steps involved in bringing an existing application from an older version of its development/deployment environment to a newer version. When I think of "migration" I picture a flock of birds flying south for the winter or a long line of cars crossing the border at Tijuana. Fortunately, migrating an eDeveloper v9 application to eDeveloper V10 is considerably less exhausting than either of those images might imply. Keep in mind, that eDeveloper applications cannot be converted to eDeveloper Discovery, since the purpose of Discovery is to introduce new developers to the Magic paradigm. Migration is therefore available only to eDeveloper Express and eDeveloper Enterprise.
eDeveloper V10 offers an entirely new approach to creating, storing and handling your eDeveloper application development projects. One of the things that you will notice is that eDeveloper V10 does not support the previous version's export file structure. But not to worry, a conversion utility is provided.
So crossing the border to eDeveloper V10 involves three easy steps: prepare your application for export, export the application, and run the conversion utility. It's just that simple, but let's look into each step a little more deeply and then discuss the three utilities available once your application has been migrated.
Preparing Your Application for Export
Prior to exporting your application, you should modify your application by replacing any unsupported features that you may have used with new approaches. In this fashion, you will ensure that no program information gets lost during the conversion process.
Unsupported Features
A number of older features have been removed: DVAL3, ESTR, FLOW3, Pref, ISTR, IVAL, LSTR, WebRef, EVAL, RVAL, RSTR, LVAL, STR3, TSTR3, TVAL3, VAL3, and the Euro functions, EuroCnv, EuroDel, EuroGet, EuroSet, EuroUdp. All of these were deemed unneeded or superfluous for one reason or another. So make sure to remove them from your application if you happened to use them in the past. Chances are you did not use these functions anyway, but you should check. And remember, while you do not have to do anything to prepare for features that have been renamed, about ten functions have new names in eDeveloper V10. So the conversion utility will change these automatically, such as changing ASC to ASCIIVAL, etc.
Changing Memo Attributes
You also need to know that any variable with a Memo attribute in your v9 application is going to be changed automatically to an Alpha attribute. Database fields that had Memo attributes will be converted to Alpha attributes with Memo storage. And of course, the VarAttr function will no longer return 'M' for Memo as this is no longer an eDeveloper attribute. But once again, don't worry, the conversion process will not automatically change expressions with the VarAttr function. Nevertheless, you should probably search for the string VarAttr to see where it is equated with 'M'. You will want to adjust your program in these rare situations, because VarAttr will no longer return the value 'M'.
A Fond Farewell to Web Online
"Web Online, we're glad we knew thee, but alas it is time to departeth." Yes, Web Online is that old and it is time to abandon this approach if, tsk, tsk, you hadn't already done so. To be clear: Web Online is not supported in eDeveloper V10. Older forms with the Web Online Response interface type are not supported in eDeveloper V10. The conversion utility simply removes these types of forms from your application. So any existing Form Output operation pointing to these forms will not point to a form in the converted project. Magic recommends that you remove any form of this type before exporting your application.
And HTML Forms Must Get the Boot As Well
As a result of improvements and greater flexibility in the new Merge capabilities, and to prepare the way for even greater enhancements in the future, eDeveloper V10 will not support forms with the HTML interface type. Once again, the conversion utility simply removes these types of forms from your application, and any Form Output operation pointing to these forms will not point to a form in the converted project. So Magic recommends that you remove any form of this type before exporting your application.
So this change implies a number of changes from the way things used to work: 1) The HTML property has been removed from the Style section of the property sheet of variables, columns and models. 2) The HTML class has been removed from the Model repository. 3) The Internet Development File Root property has been removed from the Project properties. 4)The Internet APG is not supported. 5) The HTML Merge Interface Type is now named Merge. The Conversion utility will convert the HTML Merge values to Merge.
As you get deeper into eDeveloper V10, you will see this as an enhancement with a more flexible and useful approach to Merge.
Goodbye to the Old Browse Function
The browse function was rather single purpose and it is simply more flexible to replace this with an Invoke OS Command operation that gives you the flexibility to do more than just Browse. So, as a result, the Browse operation is not supported in eDeveloper V10. Magic recommends that you remove any Browse operation before exporting your application. Keep in mind, however, that the Conversion utility will replace the operation with an Invoke OS Command operation.
Other Unsupported and Removed Properties that Will Not Convert
The Multi User Access setting has been removed from the Environment dialog box.
A number of older Euro Support features have been removed because they are simply not needed any longer. First of all, the European Currency Conversion File environment setting was removed from the External tab of the Environment dialog box. The EuroFile environment setting was also removed from the MAGIC_ENV section of the Magic.ini file. Needless to say, the Base Currency and European Currency Conversion File application properties were removed too. And as mentioned above, several Euro functions are no longer supported.
The browser client of old was a Java applet. No more. To reflect changes in the most commonly supported client applet technologies available for Internet Explorer, the Java option has been removed from the Browser client technology setting in the Server tab of the Environment dialog box.
We used to have a separate generator called the Java Component Generator. This concept has been significantly expanded upon to allow composite objects of all types to be generated, including your own ability to write composite generators. All of these are now found in the new and exciting Composite Resource Repository in eDeveloper V10.
Significant improvements in XML handling have been added in eDeveloper V10. You can learn about these in greater detail in one of the recent XML Webinars in the Magic Software webinar archives. Anyway, the old XML Component Generator has been removed to make way for these enhancements.
The rather obscure "Internet Development File Root" property was removed from the Application Properties dialog box.
Three columns have been removed from the DBMS repository:
In corresponding fashion, some Magic.ini settings were removed from the MAGIC_DBMS section: OnePhaseCommit, TwoPhaseCommit, NotTransLockExcl and TransLockExcl.
Several columns and properties have also been removed from the Database repository. The Magic Server column was removed from the Database repository. The Common Data Dictionary property was removed from the Options tab of the Database Properties dialog box. And the XA Transactions property was removed from the SQL tab of the Database Properties dialog box.
Out the door forever, I should add. The Internet APG for a table or task is no longer supported. The Internet tab was removed from the APG dialog box.
The Export Document option was removed from the Operation list in the Export/Import dialog box.
Finally, (well, with blogs, nothing is ever final) the Studio rights have been removed.
Colors and Fonts
This next consideration is optional. Some of you may prefer the new eDeveloper V10 color and font settings. Nevertheless, if you want to maintain your application's colors and fonts, you should set the Application color and font definition files and the Internal color and font definition files of the converted project to be directed to the color and font definition files of version 9. This is a onetime setting change for each application and project.
Security File
You will likely want to use your security file (such as usr_std.eng) from the previous version, but you do not have to. If you decide to convert your existing security file, run the usrupd.exe utility from the command line. The syntax is:
usrupd *input* *output*
*input* is the name of your current file name and *output* is the name that you want given to the file that is created by the usrupd.exe utility. And you should keep in mind, very importantly that in eDeveloper V10 you can only assign runtime rights.
Terminology has changed too
I won't get into terminology changes here because I don't think they are relevant to the migration itself. But you should definitely familiarize yourself with the new terminology in eDeveloper V10 as compared to the prior version.
Next time:
In my next blog entry, we'll discuss the export and conversion steps. So stay tuned.
