Copy the Applications from the OpenROAD 6.2 Environment to the 12.0 Environment
Follow this procedure to migration each OpenROAD 6.2 application to OpenROAD 12.0.
1. In the OpenROAD 6.0 development environment, use the XML export feature to export the application from the OpenROAD 6.0 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.
2. In your 12.0 development environment, use the XML import feature to import the application into your 12.0 source code repository. You do this by specifying the –xml flag with the importapp utility.
3. Use the XML export feature to export the same application out again from your 12.0 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 6.2 application is imported into 12.0, 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 12.0 import path, ensuring that your application has been exposed to the full range of import processing before you start editing it.
4. If you plan to migrate to a UTF8/Unicode environment and you use varchar variables to handle extended ASCII characters, in your 12.0 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 6.2, migrating this application to an OpenROAD 12.0 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.
5. Compile all the components in the application using the 12.0 development environment.
Last modified date: 06/25/2024