If you’ve already upgrated to the latest Forms version (currently 18.104.22.168) you’ve maybe encountered following problem:
If you use a cursor, that is specified in a package specification within your forms and define a rowtype based on that cursor that is fetched into the rowtype in a different other part of the form (in my case the package body). If you then try to compile you may get the error 801 internal error [unexpected fragile external reference] from figure 1.
Figure 1: Compilation error
We’ve opened a service request for that problem in metalink and received an answer, that I would like to show you in this blogpost. There is also a bug filed as well: Bug 23250870
The solution for the compilation error and it’s solution is described the following document in Metalink. It says, that the base bug is a PLSQL bug.
Rather than providing a patch for that problem, Oracle gives the information, that you have to set following variable to one to enable the compilation:
If you set a path variable in CMD before starting the Forms Developer and then execute frmbld.exe you are able to compile a module that contains a construct like:
PACKAGE Test IS
cursor c1 is select name_object from all_obj;
Package body Test is
Procedure p1 is
fetch c1 into master_rec;
Registry entry & environment variable
Warning: Changing the Windows registry can mess up your OS.
I’ve tried to also create a registry entry in a Windows machine under HKEY_LOCAL_MACHINE\Software\Oracle\KEY_OracleHome1 and set it to “1” so you don’t have to execute a batch before running Forms Builder. Also I have tried to create a new environment variable. Both options enable the Forms Builder to compile. But I had complications while compiling a bigger customer forms module, when I hit directly Ctrl+shift+k – the Forms Builder crashed when I did not connect to the database before hitting the hotkey.
I’ve migrated my first Oracle Forms module last week. It is the first time for me to be part of a migration project. The colleagues that I am working with instead have a high experience when it comes to ADF and migrating Forms to this technology, while my focus the last couple of years was mostly Oracle Forms. I think that is a possible scenario for many projects, where the aim is to migrate Forms to ADF.
So how can Forms developers start to migrate their application? The first step for me was to gather information on ADF, its architecture and the basics. I tried this with some self training, online materials and the help of my colleagues. When I came to the point to migrate the first module by myself I used the Forms Developer & PITSS.CON to understand how the form worked before and how the workflow was. There are people out there, that tell you that tools won’t do the job for you – and I agree. But they can make your job as a developer much easier. My colleague Mathias Waedt has developed a plugin for JDeveloper, that helps you as a developer when struggling with a migration. It helped me to understand which objects in ADF have been generated and which not. It showed me, were I had to put my effort into. The plugin fetches its information from the PITSS.CON repository.
When the plugin is started it shows the basic information of the project like the database scheme, the names packages for the different objects (entity objects, view objects, etc.) and some other parameters. With a click on the details tab it is possible to see information of single forms. The form summary tab displays information regarding how many Forms objects already have been transformed to ADF components with PITSS.CON. This gave me a first overview of the upcoming work for that specific module. I saw, that most of the graphical objects were generated and only small modifications were neccessary here, while I had to modify the business logic that was formerly located in triggers and program units.
With a click on Form Details it is possible to see which objects have been generated and which not. So for me as a newbie it was a big relief to use this kind of a checklist.
You can see all the objects from Oracle Forms and the corresponding generated objects in ADF – with a doubleclick you will directly jump into the generated object (e.g. Java Bean). As a future functionality it is planned to mark the objects that were added by the developer and are considered to be done. So you can work your way through the module without the danger to forget a functionality that was present in Forms up to 100%. The plugin is currently in the beta phase.
Today Oracle Forms 12c was finally released – as you can see in Michael Ferrante’s Twitter post, who is the Product Manager for Oracle Forms:
Check out the Oracle Forms Product Page, where you can find the Release for download:
So if your application is still running in an version prior to Release 11gR2 you now should really consider to upgrade to be able to use 12c and its features soon. I will download & install 12c in the next days and tell you here what my experience was like.