Migration Guide : Upgrading from OpenROAD 4.0 or 4.1 : Phase 4: Go Live
 
Share this page          
Phase 4: Go Live
Ingres does not support using OpenROAD 6.2 to run OpenROAD 4.1 application images. You must recompile and reimage your applications using OpenROAD 6.2, then redeploy them to the client installations.
The resolution of certain issues may involve changes to files in %II_SYSTEM%\ingres\files, for example color or font changes, or changes to Ingres environment variables, in upgraded installations.
Individual organizations will have their own rollout mechanisms for OpenROAD applications. These must take into account the following points:
Ingres does not currently support the installation of multiple OpenROAD instances on a single computer (unless individualized within virtual machines). All applications that need to coexist on a client computer must be upgraded together.
If you run an OpenROAD client/OpenROAD Server architecture and are currently using OpenROAD 4.1 SP2 or a previous version, the “date without time” handling introduced in OpenROAD 4.1 SP3 will affect your applications. (See Incorrect Truncation of Date-times.) In this situation, all clients and all servers using this architecture must be upgraded or rolled back together.
OpenROAD applications on UNIX require a different version of MainWin from those on 4.1, with different system requirements. (See UNIX Installation Error.)
In every other respect, a live environment appropriate for OpenROAD 4.1 deployment is appropriate for OpenROAD 6.2 deployment.
Installing OpenROAD 6.2 does not require uninstalling OpenROAD 4.1. However, for rollback you will need to uninstall OpenROAD 6.2 (using InstallShield) before reinstalling OpenROAD 4.1 on the client.
To apply the recommended patch (13047 or higher) after OpenROAD 6.2 is installed, you must stop the Ingres installation, carry out the patch instructions, and restart Ingres afterward. To receive the patch, contact Ingres Support at http://supportservices.actian.com/support-services/support#contacts.
Other considerations, such as archiving the means to recreate a fully functioning 4.1 environment so that you can recover after an unsuccessful rollout, have already been highlighted.