For the database:
(1) Always shutdown your database and have a valid backup before starting the conversion:
proshut <db-name> -by
probkup <db-name> <path/db-name.pre>
(2) If you are using AI, stop after-imaging:
rfutil <db-name> -C aimage end
(3) If you are migrating from Progress 7 or earlier version, it is required to convert the database to version 8. See Articles 000028229 and 000019667 for instructions on how to do this.
(4) If you are migrating from Progress 8 and your database is a single-volume, it is required to convert it to multi-volume database. See solution 00001128 for instructions on how to do this. df
(5) Truncate the BI file using Progress 9:
proutil <db-name> -C truncate bi
(6) Convert the database with 'conv910' command using OpenEdge 10:
proutil <db-name> -C conv910
This should take under 5 minutes, regardless of your database size.
(7) Backup the new database using OpenEdge 10:
probkup <db-name> <path/db-name.post>
(8) If you are using AI, start after-imaging:
rfutil <db-name> -C aimage begin
You may also consider modifying the database structure and schema to make use of the new Type II Areas and other new features and database startup parameters which may help with performance, for example:
(a) Planning Storage Areas, i.e. not to have all tables and indexes in the "Schema Area".
(b) A "proutil <db> -C tabanalys" command will reveal the average size of records in each table, from which you can plan the optimal number of records-per-block for tables in your database structure file (.st).
(c) The areas are added to an existing database using "prostrct add <db> <db.st>", then tables and indexes can be moved to newly planned Storage Areas with "proutil db -C tablemove <table> <index>"
(d) The 'proutil' utility has an option "-C mvsch" which allows reducing the schema area to a minimal size.
Alternatively, the database can be migrated using an ASCII dump and load to migrate from any version directly to OpenEdge 10.x.
For the Application:
Recompile the entire application code. Note that a number of 4GL statements are being deprecated.
Make sure to test the application under OpenEdge 10.x to ensure everything still works as expected.
After these steps, it is highly recommended to review the application code and modify as required to replace deprecated statements with alternatives to prevent major migration issues in the future.
It is also recommended to review the new features and technology and implement those where applicable. For assistance on how to get the most out of the new OpenEdge 10 features, it is recommended to contact Progress Professional Services.
The following should also be taken into consideration when migrating:
- Not all OS platforms supported in earlier versions are supported in OpenEdge 10.
The OS may no longer be supported by it's vendor, or OS issues may prevent OpenEdge 10 from running correctly (as is the case with SCO OpenServer).
Please check with the Sales department which OS platforms are supported and which would be the preferred OS to move to if required.
- Increase in r-code size. R-code segments now use 32-bit offsets as opposed to the 16-bit offsets of previous releases.
This eliminates a number of practical limits for larger procedures, but it also has the side-effect of increasing the r-code size by up to 45 % depending on the contents of the procedure.
The following features have been removed either due to product retirement or due to external factors:
- SQL89 support
- Report Builder (Report Engine is still present to maintain backward compatibility)
- ActiveX Proxy (due to Microsoft losing the Java lawsuit we may no longer distribute the required Microsoft components)
