December 12, 2007

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.

12 comments:

Patrick Wolf said...

In my opinion there is a big difference between not being able to read the full source code and being able to read a few literal values in a binary file. That doesn't have to do anything with "save". But still a good point with the readable literals, because a lot of Forms developers do not know and are wondering why someone knows there hardcoded password in the code... ;-)

About the mixing of plx/pll and using the wrong one. I think that's no issue if you have cleanly setup your deployment environment.

Patrick
PS: You should probably change the language of your blogspot blog to English, because the "Kommentar veröffentlichen", ... shows still in German. Not everybody is able to read that :-)

Gerd Volberg said...

thanks Patrick for your comment. And many thanks to your blog in which you demonstrate how easy it is to duplicate a blog in two languages :-) I've done the same now with Talk2Gerd

Anonymous said...

Hi,

Interesting information.

Thanks ..... Saji Alexander.

Unknown said...

There would be a C)

Use only plx while developing the application. It's faster and there is no problem with timestamp.

Is this correct? Do you see any problem with this option?

Thank you

Gerd Volberg said...

Hi Roberto,
I never found a testcase, in which the PLX ist faster than the PLL. If you have one, please describe us an example. I'm interested in finding one.
Bye
Gerd

Unknown said...

Hi,
Does this still apply for version Forms 11.1.2.2? Are there any other locations (ie. registry, formsweb.cfg or custom_name.env that Forms Services searches in a default order?

Thanks for this note. Just looking to clear up a situation we are having.

Unknown said...

Hi,

Does this still apply for Forms 11.1.2.2? Is there a default search order location(s) (registry, formsweb.cfg and custom_default.env that Forms Services looks at while trying to find a fmx, mmx and PLX?

Thanks

Gerd Volberg said...

Hi Rolando,
this behaviour never changed since Forms 6.
Bye
Gerd

Unknown said...

Hi Gerd,

We are fighting a weird issue in how PLX files get cached by Windows. We make a change to a PLL (simple message with different debug text) file then compile all then compile to get PLX. No errors. We then recompiled the FMB against the new PLL and get a new FMX. We deploy PLX and FMX to Forms (11.1.2.2) deployment area. We do not see the NEW debug message. We see the previous modified version debug message. I am working with Oracle but I figure I ask the Forms community for any other insights.

Thank you for your time!

Gerd Volberg said...

that's easy Rolando :-)

If you search in all of your PATH-directories for the Library (PLL and PLX), then you will find an old version, which you didn't actualised.

Bye
Gerd

Pallab said...

Any idea? how to find package body inside a PLL or PLX. In a folder there are hundreds' of PLL and PLX. I want to locate one package body.

Gerd Volberg said...

Hi Pallab,

you should create a pld (textfile) for each pll.
Use FILE - CONVERT - PL/SQL-Librarys
Convert: Binary to text

You have to do that once for each library manually or through a batch for all 100 in a loop. Therefore you use frmcmp.exe with all the parameters you need in your case.

Have fun