September 27, 2010

Upgrading IE in the local development environment

If you ever have a stable running IE 6.0 or 7.0 for your Oracle Forms development and you think: Let's use the IE 8.0 or 9.0.

Then you may run into these problems:

After the IE 8 Installation you run your application through the Run-Button in the Forms-Builder and see this:

oh no... what an ugly URL you think...

Now we have to find the problem:

First point is, that the JInitiator isn't running against the IE 8 and we have to switch to an alternative. OK let's use the sun-plugin.

Second pitfall may be, that switching to the new "config=my_sunconfig" didn't run with the local forms developer, although you can run the main application on the Application Server.

This problem occurs, because you may forgot to check the formsweb.cfg on your local machine.

After changing the environmant to sun-plugin-parameter-values there might be another problem, but only in seldom cases: Under edit-preferences you can set the path for your Internet Explorer. Check, if this is correct, or change it to the new IE 8 destination.

And now have fun with your IE 8

July 09, 2010

New Layout

I updated the templates a little bit of my talk2gerd. These are the new features:


- all followers of my blog are welcome here


- here you can see all the different labels I used in my blog. Click on a label and you see only the postings with that label on it.

have fun

June 09, 2010

I just submitted "Forms 11g and the iPhone" for the DOAG Conference 2010

In some weeks the Call for Papers for the German Oracle User Group (DOAG) Conference 2010 ends.

My plan is to hold a presentation about Forms 11g and the iPhone.

The main topic of the presentation is, how you can extract modules from big Oracle Forms Applications and recreate them in a mobile version on the iPhone.

The presentation-testcase shows, how much more efficient it is to have a time-reporting on your mobile device versus the old technique, where this app was part of a big legacy application.

Another topic is to show, how you can communicate bidirectional between Forms 11g and the iPhone App. Using Advanced Queueing in Forms and Push Notifications in the App is the solution.

5 months to go and I hope I get a slot in the conference.

May 05, 2010

Migrate your charset to UTF8, annotation to step 3

After migrating to UTF8 you may have problems with your report-server. This is, when your reports cannot be displayed and internally the server throws a "Canceled as server is shutting down"

With UTF8 you need a bigger cache-size in "report server-parameter". Easiest way, when you run into problems, double up the value of the parameter.

Try it

Back to part 3 of the article

April 28, 2010

Migrate your charset to UTF8, step 3

Applications without Reports are useless :-)

So we have to change some things in the Reports Environment to enable UTF8 in PDF-Output.


you have to edit in your OAS Report-Server the report-config:

Add one "environment id" per section. A section is in this example development, test and production. After that, each section has defined it's own NLS_LANG and report-path.


You can use the new sections through Forms. Before starting the report you add another parameter to the paramlist:

Add_Parameter (V_ParamListe, 'ENVID', TEXT_PARAMETER, 'NLS-PROD');

Now you can control the NLS_LANG of your reportserver.


Last checkpoint for your reports is the correct mapping between your fonts and your TrueType-Fonts (in this case we have a windows-system)

Edit the file "uifont.ali" in the directory \tools\common and add the following lines in the section [ PDF:Subset ]

Arial..Italic.Bold..             = "c:\windows\fonts\arialbi.ttf"
Arial...Bold..                   = "c:\windows\fonts\arialbd.ttf"
Arial..Italic...                 = "c:\windows\fonts\ariali.ttf"
Arial.....                       = "c:\windows\fonts\arial.ttf"

"Courier New"..Italic.Bold..     = "c:\windows\fonts\courbi.ttf"
"Courier New"...Bold..           = "c:\windows\fonts\courbd.ttf"
"Courier New"..Italic...         = "c:\windows\fonts\couri.ttf"
"Courier New"                    = "c:\windows\fonts\cour.ttf"

"Times New Roman"..Italic.Bold.. = "c:\windows\fonts\timesbi.ttf"
"Times New Roman"...Bold..       = "c:\windows\fonts\timesbd.ttf"
"Times New Roman"..Italic...     = "c:\windows\fonts\timesi.ttf"
"Times New Roman"                = "c:\windows\fonts\times.ttf"

In this example windows has its fonts in the directory c:\windows\fonts\

have fun

To be continued with Migrate your charset to UTF8, annotation to step 3

Back to part 2 of the article

April 07, 2010

Migrate your charset to UTF8, step 2

Now, after changing the NLS to UTF8 we may have problems with hotkeys.

That's because the nls-change to UTF8 will now use a different resource-file. Instead of fmrweb.res the fmrweb_utf8.res is used. The resource-files are located in the forms-home-directory.

If you have used "term" in your formsweb.cfg - otherparams, then you point hardcoded to a specified file. Here you have to change the value of the parameter or you have to exchange the content of the file.

e.g. changing the value of the parameter:
old: otherParams=term=\fmrweb.res
new: otherParams=term=\fmrweb_utf8.res

After this changes you can use the same hotkeys like before

To be continued with Migrate your charset to UTF8, step 3

Back to part 1 of the article

March 31, 2010

Migrate your charset to UTF8 in 3 steps

What do we have to do in our forms application, when the database in the backend is upgraded from a single-byte charset to a UTF8-charset.

First Step

Make a backup of your forms-sources, your local forms installation and your application server configs.

After that change the NLS_LANG in your registry. You can create a backup of the parameter, through creating a new parameter named "NLS_old" with the value of the old NLS_LANG-value. The new value of NLS_LANG is for example "GERMAN_GERMANY.UTF8". This change is for your local forms builder, when you recompile your forms sources.

Now we can edit our local default.env. If there is a line with the NLS_LANG, then change the value to the UTF8-value (see above) or create a new line with the NLS_LANG. This change is for our local OC4J instance only.

Do the same change on the application server (use the OEM for edits)

These changes were the basic environment-changes we need for UTF8.

To be continued with Migrate your charset to UTF8, step 2