Citation :
Definition of Terms
A MINOR UPGRADE is identified by a release or patchset in which the first digit of the version number remains fixed but other digits increase. For example, 2.1 is a minor upgrade with respect to 2.0, and 6i is a minor upgrade with respect to 6.0
A MAJOR UPGRADE is identified by a release or patchset in which the first digit of the version number increases. For example, 9i is a major upgrade with respect to 6i
A MAJOR RELEASE is a set of releases and patchsets that share the same first digit; in other words, a set of releases that are minor upgrades with respect to each other. For example, Release 6i together with all of its subsequent patches and upgrades is a single major release.
Any upgrade may contain new features, functionality, enhancements, and/or bug fixes.
Install Compatibility
Question:
Can different major releases, for example Forms/ Reports 6i and Forms / Reports 9i, co-exist in the same Oracle Home?
Answer:
This can vary from release to release and also depends on the platform. Therefore always refer to the release install guide and/ or release notes. The general recommendation is to install different releases/ upgrades into separate Oracle Homes (directory structures).
Module Design Time Compatibility
Question:
Does design time compatibility exist between versions / releases, for example, can a module saved in Forms 9i Builder be opened in Forms 6i Builder?
Answer:
A module created in a newer major release cannot be opened in a previous major release. Similarly a module that has been upgraded to a particular major release, whether explicitly by an upgrade process or implicitly by saving the module in the later major release, cannot be opened in an earlier major release. For example, a module created in Forms 4.5 or 6i can be opened and edited in Forms 9i/ 10g. In the case of certain upgrades, it may be necessary to apply an upgrade process (e.g Forms Builder PL/SQL v1 to v2 conversion utility) to each module before the module can be opened. Thus, across major upgrades, source modules are forwards compatible but not backwards compatible.
A module can be upgraded directly from one major release to a release that is two more major releases later without passing through each intermediate major release. This compatibility, however, is not guaranteed and sometimes it may be necessary to upgrade through each intermediate major release. e.g. It is only supported/ certified to upgrade Forms 4.5 modules to Forms 9i/10g via Forms 6i
Exception: Within a major release, (that is, across minor upgrades), source modules (fmb, rdf files) are backwards and forwards compatible. That is, a module created in any release within that major release can be opened and edited in any other release within that major release. NOTE: a module created in a later release is not guaranteed to recompile and run in an earlier release if the module makes use of features added in a later release. For example, a module created in Release 1.6.1 that uses the built-in WEB.SHOW_DOCUMENT will not compile in Release 1.3.2.
Module Run Time Compatibility
Questions:
Does runtime compatibility exist between versions / releases, for example, can a module generated under Forms 9i / 10g be run in a Forms 6i / Oracle 9iAS Rel 1 environment?
Do runtime modules have to be re-generated when upgrading from one major release to another, for example, can a Forms 6i fmx be run directly in a Forms 9i / Oracle 9iAS Rel 2 environment?
Answers:
Runtime compatibility is not supported between major releases. A module generated under Forms 9i / 10g cannot be run in a Forms 6i / Oracle 9iAS Rel 1 environment.
Generally speaking modules must be re-generated when upgrading from one major release to another. A Forms 6i fmx cannot be run directly in a Forms 9i / Oracle 9iAS Rel 2 environment. The source fmb would have to re-generated using Forms 9i Builder or Compiler first.
Within a given major release, a minor upgrade can be installed without requiring regeneration or any other modification of currently deployed existing applications created in the same major release. In order to run several applications created with different versions of a single major release, best practice is to determine the latest minor upgrade used to create these applications. Install the run time environment corresponding to that version, or later. For example;
If two applications were created using Release 6.0 and Release 6i respectively, install the runtime environment for Release 6i
Generally speaking, a later minor upgrade within a given major release can always read and execute modules generated with an earlier minor upgrade of the same major release. The generated format of runtime modules, however, may change from time even within a minor upgrade. It is sometimes the case that a generated (compiled) module cannot be run in an earlier runtime than the release used to generate (compile) it. In this respect, Forms 10g (9.0.4) can be considered to be a minor upgrade to Forms 9i (9.0.2) - reference:
@Note 261964.1 Can 9.0.2 Forms and Reports Modules be Run on 10g (9.0.4) Without Re-Compiliation?
Note also that behavior of deployed applications may change in minor ways in response to bug fixes. Wherever possible attempts are made to minimize these changes. In particular, behaviors that contradict documented behavior are liable to be corrected. Work-arounds may need to be coded in order that applications will function correctly when such bugs are fixed, or existing work-arounds may need to be removed when deploying a minor upgrade containing a relevant bug fix.
|
c'est chaud... si ce n'est pas trop volumineux, je te conseille de créer des fichiers plats (via spool) à insérer dans la 9i (via SQL*Loader). Pour le reste, il faut référencer et recréer tous les objets à la main.
et y a pas d'autre alternative 
j'vais pouvoir postuler pour la maitrise de voyance