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
Gerd

New Layout

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

Followers

- all followers of my blog are welcome here

Labels

- 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
Gerd

New Statement of Direction, May 2010

This is the new Statement of Direction from May 2010. (My last SoD-Post)



Here are some links to older Statement of Directions:

SoD Oracle Fusion 2010 / 05
SoD Forms 2009 / 07
SoD Forms 2008 / 07
SoD Forms 2007 / 11
SoD Forms 2005 / 09
SoD Forms 2005 / 05
SoD Forms 2005 / 03
SoD Forms 2004 / 06

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.
Gerd

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
Gerd


Back to part 3 of the article

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.

First

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.

Second

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.


Third

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
Gerd

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

Back to part 2 of the article

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

Migrate your charset to UTF8 in 3 steps

What do we have to do in your 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