The new german Talk2Gerd

Today I learned from Patrick Wolf, how easy it is to duplicate a blog into another languages. This link here is now the german version of Talk2Gerd.

And last but not least, here is a picture of my company after snowfall... and we had a lot of snow in the last years:

Libraries: PLL vs. PLX

One big problem while developing an application is the question: Should I use attached libraries as *.pll or *.plx?

Let's have a look at some cases:

A) You use pll+plx while developing the application. The Forms Builder uses the working directory C:\Forms and the FORMS_PATH has an additional path to the directory C:\Forms\Lib. The Sourcefiles have the name Lib.pll, the Menu.mmb and EMP.fmb.

If there is a generated Lib.plx in c:\forms or c:\forms\lib, then this is the version, which will be used at runtime.

This is the direction of how Forms searches for attached libraries:

1) If Lib.plx is in your working directory - take it
2) If not found, search in the FORMS_PATH for Lib.plx
3) If not found, search in the working directory for Lib.pll
4) If not found, search in the FORMS_PATH for Lib.pll
5) If the library can't be found - Forms raises an error

This is identical to menu-mmx and forms-fmx

If the plx in the local working directory is an older version than the pll, this will cause big problems while running the forms-application. Finding errors is very tricky, if the developer didn't look on the timestamps of the libraries.

B) You use only pll's in your application.

You have no problems while developing the application or at runtime. If a library in your working directory didn't exist, then the library can be found in the FORMS_PATH.

Summary:

I never use plx because I saw many projects run into the plx-trap.

Many developer say: plx is faster, but I never had performance problems with the pll's.

Other developer say: plx is only the compiled code, so nobody can steal my sourcecode or something valuable from within the code - in that case try this example:

Create a library with a package and this variable:

PACKAGE Const IS
  HiddenPW                     CONSTANT Varchar2 (100) := 'HiddenPW';
END Const; 

Generate the plx and open it in an editor. Search for "HiddenPW". You'll find the name of the variable and the string associated to the var. That's not secure in my eyes. Only the sourcecode is hidden. I think, that a pll on an Application Server is secure enough.

If the application is standard software and not for free, then you must use the plx-technique and wrapped packages in the database.

DOAG Top News: Forms 11g

The German Oracle User Group (DOAG) has launched a little Forms 11g note from me as their actual Top News.

I wrote some lines about the new features of Forms 11g and the huge capabilities in the new SOA world of tomorrow. Here is the translation:

Forms 11g unterwegs in Richtung SOA : Forms 11g's direction to SOA

After 6 years is this the first Forms Version which integrates new features into the Forms Builder. The two new important features found are:

The first one is the communication between the database and Forms via Advanced Queuing. There is a new object-typ called Event, who communicates with a queue. New data in a Queue starts an event-trigger, which runs in Forms.

The second highlight is the Javascript-API. HTML-pages can exchange data with Forms via Javascript. In the old days you could do this only using java applets. With the new technique you have WHEN-CUSTOM-JAVASCRIPT-EVENT-trigger which can be used from the developer. The communication runs in both directions and it's possible to change data in the HTML-page through Forms via Javascript

Those two new techniques are indications, that Oracle Forms is ready for the future. It is one of the main SOA-parts of the new Oracle Fusion Middleware 11g.

Additional information to Forms 11g can be found in the German Forms Community

Thanks to DOAG

New Statement of Direction, Nov. 2007

This is the actual timeline for Oracle Forms