Oracle Developer Tools and ThoughtsEnterprise IT Tools and Thoughts, dealing mainly with Oracle Developer tools (Forms, Reports, APEX)

One of the more frustating experience you can have when migrating to Oracle Forms 10g is the fonts problem.
In Oracle Forms 6i, users are generally standardized on Windows and in this way, they have access to the usual fonts such as Arial, Times Roman, Courrier and Courrier New. When printing reports, either direct or through a PDF, the same fonts are used as is and the output is a true copy of the rdf.

However, on 10g and if the server is UNIX-based, then a whole number of issues will arise. The first one is due to the fact that the usual Windows fonts are no longer available on UNIX. Second, the fonts on UNIX are quite limited and in this case  fonts  such as Arial are outputted as Helvetica (in reports server terminology, this is refered to as subsetting, embedding etc.).

Now, if you really want to have the same fonts you have in your RDF, then you need to install those fonts on UNIX.  This is where it becomes quite nightmarish. In our case, we were able to get either Arial bold or Arial Italic but not both at the same time, at least for the time being.

To solve this font problem, We are  following these Metalink notes:
NOTE:261879.1 Configuration Script to add Common Windows Fonts to Unix 9i, 10g R1 and 10g R2 Reports Server
NOTE:272063.1 Using Reports PDF Subsetting, Font Size and Styles Bold, Italic, Bold-Italic Are Ignored
NOTE:419045.1 Italics are Reversed and No Bolding of Arial Font on Sun 64-bit

Some of our modules made use of Oracle graphics in the 6i version (C/S). We spent some time thinking about installing Graphics on 10g but eventually we opted for the BI bean instead. Why ? very simple because you can easily duplicate what you have in 6i with very nice features from the BI bean.

There might be a slight learning curve here but it really boils down to reading the instructions that come with the BI bean and some testing. That’s all.

Note: make sure you set your classpath to the folder where you have your JARs.

In order to follow the migration efforts from 6i to 10g, I quickly put together a dashboard that shows the four states : migration-testing-correction-acceptance for the modules in our application.

On the left side, we can click on the buttons to show the global stats, stats per analysts, stat per application and the modules that are problematic.

The gauge is a Javabean that I put together following an example I found on the OTN network. There are a number of properties that can be set on this javabean. I really did not spend that much time on the graphics part of the gauge but eventually I will have to do it since our application itself might include some versions of this gauge in the future.

There is also a timer (invisible on this canvas) that I borrowed from the Oracle foms 10g demos. The timer is set to 20 min and a custom event trigger is set to query a table that holds the module’s names and their states.

Now that we have crossed the midway phase in our conversion phase, we started the evaluation of all the client side functionalities we used to have in our application. Fortunately, in Forms 10g, webutil comes already pre-installed.

Read the rest of this entry »

One of those things that can irritate you for more than you can care of: the mix up in dates. That’s an old story for those dealing with the Oracle Db but in our case, that was something that bothered us for more than a week before we found out that we were missing the environment variable NLS_DATE_FORMAT in our report server setup.

Read the rest of this entry »

Last week, one of our senior DBAs made a comment  regarding our current migration. Essentially, he was referring to Oracle APEX (formerly HTML-DB) and whether we looked at Forms to APEX conversion.

Management decided a while ago that we will be migrating to Oracle Forms 10g given that the in-house expertise is mostly Oracle Forms.

Read the rest of this entry »

Any software under development should have at least two essential systems, namely a source control system and a bugtacking system.

When we planned our migration, we did include a source control based on subversion but a bugtracking system was really not thought of. While we planned on using MouliForms as our migration tool, we did not envision that we also needed to track bugs within MouliForms and our application as well.

Read the rest of this entry »

In the course of adapting our reports and submission forms to 10g, some of our users asked for a specific request. In version 6 of our application, users can either request a screen preview or print directly to the local printer.

In 10g, the local feature is lost because the processing is now done in the middle-tier. There are a number of alternatives, each having its own advantages and drawbacks.

Read the rest of this entry »

Here we are at the end of the second week in the migration of a mission-critical Oracle Forms 6 application. The main points we dealt with are:

• AIX file transfert and compile processes
• LOV visual appearance (differences between 6 and 10g)
• Report rdf structure search in a batch mode from a keyword-based file

Read the rest of this entry »

One of our developers raised the question about finding specific strings within our Reports. For example, we might have to check whether a query has schema name used in building up the query. That can be a problem if we need to move the tables to another container (this will break the query since the schema name reference is no longer valid).

So we might be looking at searching strings such as: INVENTORY. or RESOURCES. etc…

But since we have more than 500 reports, it was suggested that this should be done in a batch manner. Given that Oracle Reports does not have an API similar to JDAPI for Oracle Forms, I looked at another option suggested by others (AMIS among others). This one involves converting the report from rdf format to XML, parse the DOM model and do some regexing (search and replace) and then convert back to rdf.

So I whipped up a small JAVA class to MouliForms in order to check the validity of this approach on a number of reports stored in a temp folder. It did the job as expected but I need to do some additional testing in week 2.

But as it stands, things are looking good at the end of week 1.