We recently made a modification to a Form which was about 6.4Mb in size. The change was the addition of a button, and about 25 lines of code (which includes the comments). The filesize dropped from 6.4Mb to 4.8 Mb.

We went back to the original *.fmb, and only added the 5 lines of comments, and the filesize droppped from 6.4Mb to 5.7Mb, then we made the button and code addition and the file stayed approximately the same size.

We're new to Forms, and we've started on the 10g version. Has anyone seen anything similar, and is there an explanation?

Hi,
there is no particular reason for reduction of the .fmb file.
You should be concerned when the size increses.
The way you compile a form may increase its size.
If you find that form size increases when the form is connected
to database then open the form, disconnect from database, save
the form and exit out of designer. Then start designer, load the
form, connect to database and do a Compile All (CTRL+K).
Watch the Progress as Forms "Uncompiles" the program units.
As soon as all the program units are uncompiled hit interrupt.
Save now and the file size will be back down to the
initial size.

Forms stores a pile of compiled code in the fmx that is never used, and slows down the Forms Builder when it opens the fmb file. If you compile your fmb and save, the fmb balloons in size due to the compiled code.

If you do a replace all, change all semicolon to semicolon ( ; to ; ), this forces all program units to become uncompiled, and then save WITHOUT compiling, your fmb will shrink.

This is also a good method to use before transporting the fmb to a different database or operating system, because it automatically requires a Compile All when it is recompiled.

However, BEWARE: If your form has any referenced triggers or program units, doing the replace-all will break the referencing. Read comments below for more info.

Here is a more detailed explanation of the semicolon replacement:

If you compile a form, you will notice in the Object Navigator, that each program unit has a '+' by them that you can click and see more options. If you open the source of the program unit, at the bottom of the editor window it says Not Modified . . . Sucessfully Compiled. If you save the form, close it, and re-open it, the program unit still has this compiled indicator.

If you change anything in the program editor, the compiled indicator disappears. If you save the form without compiling, and reopen it, it is still NOT compiled.

All you are doing by changing semicolon to semicolon is forcing every trigger and procedure to become uncompiled. And then if you save the form in this state and check the fmb size, you will notice a much smaller fmb size. You will notice when you open such a form in the Builder, the open is faster, and the first compile is slower (just like doing a shift-ctrl-K compile-all). On the other hand, a form saved with all compiled code opens slower, but first compile is fast. Apparently when Oracle opens a pre-compiled fmb, it tries to verify the compiled program units.

However, these compiled program units cause problems -- we have had problems using pre-compiled fmb's transported to different environments failing in stored-procedure calls and other places. Doing a compile-all (shift-ctrl-K) clears the problem.

The bottom line is this: Storing compiled code inside an fmb does no good. Oracle has been doing it from the beginning of client/server forms, along with storing a copy of the color palette, too. In BOTH situations, this has caused issues with forms, especially when moved from one environment to another. In my workplace, we make SURE we always store production forms WITHOUT the compiled code. They transport quicker due to smaller file size, and they compile cleaner in the users environments.

Every trigger and program unit within your form will contain the ";" character so by finding and replacing all of them you are guaranteed to uncompile your form and gain the results as indicated by Steve.

In forms you can reference code. You can reference program units and trigger code, from one form to another. Then when the source code is changed and the referenced form is recompiled the changes in the source is included into the referenced form. Forms allows you to change the referenced code. In fact there is no way to lock it. But once it is changed in the referenced form. Then the link back to the source object is broken and the code is no longer in synch after a recompile.

Now with this approach of doing the global replace ';' with ';' will update referenced source code, breaking the link. So for some people this can be a dangerous thing to do.

here what you should do to remove PCode. ( reduce the size of FMB files ) using JDAPI.

<P>As an old-fashioned Forms developer, I am not sure how or where "PCode" fits into the picture. Can you (or anyone else) elaborate? What is PCode? Does it apply to development in the Client/Server world (I am still back there)?

PCode is what the Java world refers to as byte code. Its compiled code expressed as bytes rather than hardware dependent binary. Oracle has historically called it Diana, the compiled version of the plsql source code. See http://en.wikipedia.org/wiki/Byte-code for more info on byte code.

I'll let him explain what he did but the short version of how to do it is to put the jdapi jar file somewhere in the classpath, make java file with a main function containing the code above and the run that from the command line.
I'll try it out when I get some time and report back with more detailed instructions.