Copy the Applications from the OpenROAD 5.1 Environment to the 6.2 Environment
Follow this procedure to upgrade each OpenROAD 5.1 application to OpenROAD 6.2.
In the OpenROAD 5.1 development environment, use the XML export feature to export the application from the OpenROAD 5.1 source code repository. You do this by specifying the –xml flag with exportapp utility.
For more information about the exportapp and importapp utilities, see "How You Can Import and Export Applications and Components" in the Workbench User Guide.
1. In your 6.2 development environment, use the XML import feature to import the application into your 6.2 source code repository. You do this by specifying the –xml flag with the importapp utility.
2. Use the XML export feature to export the same application out again from your 6.2 source code repository to an XML export file. Then use the XML import feature to re-import this file into the same database using the –nreplace flag to overwrite what is already there.
This re-export/re-import step is only a precaution. When an OpenROAD 5.1 application is imported into 6.2, OpenROAD takes a number of extra steps to materialize the new attributes and other elements that have been added to the product. The second re-import will traverse the purely 6.2 import path, ensuring that your application has been exposed to the full range of import processing before you start editing it.
3. If you plan to migrate to a UTF8/Unicode environment and you use varchar variables to handle extended ASCII characters, in your 6.2 development environment you will need to increase the length of these variables.
This requirement is data dependent. As a contrived example, if you have a variable defined as varchar(10) that is meant to hold ten euro symbols in OpenROAD 5.1, upgrading this application to an OpenROAD 6.2 UTF8/Unicode environment without changing the length means that it will now be able to hold only three euro symbols. In this case you would need to change the variable definition to varchar(30) to reproduce the original behavior.
Generally you will not encounter any semantic character that takes more than three bytes to encode in UTF-8. It is possible that in some rare cases it can take four bytes to encode a single semantic character. As a starting point you should change any varchar(1) variables to varchar(3), and any varchar(2) variables to varchar(6). Then see if testing uncovers any other problems with the application’s varchar variable lengths.
4. Compile all the components in the application using the 6.2 development environment.