1 2 Previous Next 24 Replies Latest reply on Jan 27, 2007 6:49 AM by 558313

    FMB size shrinks dramatically

      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?

        • 1. Re: FMB size shrinks dramatically
          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.

          • 2. Re: FMB size shrinks dramatically
            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.

            I sure wish Forms had a Preferences setting labeled:
                 Remove compiled code when saving.
            Related thread:
            Re: Why does this happen - find ';', replace with ';'?
            • 3. Re: FMB size shrinks dramatically
              Thanks Steve. Could you help with just one additional piece? What do you mean when you say "...change all semicolon to semicolon ( ; to ; )..."?

              • 4. Re: FMB size shrinks dramatically
                Forms Builder -> Edit -> Find and Replace PL/SQL ...

                Find What -> ;
                Replace With -> ;

                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.
                • 5. Re: FMB size shrinks dramatically
                  i wish forms would allow LOADING multiple files on the command line:

                  C:\orant\BIN\ifbld60.EXE a.fmb, b.fmb, c.pll, etc userid=/
                  • 6. Re: FMB size shrinks dramatically
                    I would not recommend this approach. This would also change the code for all referenced triggers and will break the inheritance link.

                    The best way to handle it is to use JDAPI.


                    Michael Hitrik
                    • 7. Re: FMB size shrinks dramatically
                      mhitrik wrote
                      This would also change the code for all referenced triggers and will break the
                      inheritance link.

                      The best way to handle it is to use JDAPI.
                      I don't understand... what inheritance links would be broken?

                      And how would using JDAPI make any difference in fmb size and form compilation?
                      • 8. Re: FMB size shrinks dramatically
                        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.

                        IMO you should avoid reference code. Just too easy to break the link.

                        • 9. Re: FMB size shrinks dramatically
                          Thanks for the comments, Pat. I have added the "Beware" note above.
                          • 10. Re: FMB size shrinks dramatically

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


                            Every fix call should do the following:

                            Trigger trg=(Trigger) proc.next();
                            int i = trg.getPropertyState(JdapiTypes.TRIGGER_TEXT_PTID);
                            if(i != 1 && i != 3) { // non-referenced
                            trg.setTriggerText( UtilityMethods.replaceString( trg.getTriggerText(), ";", ";" ) );

                            }else if(i == 3){ // referenced
                            trg.setTriggerText( UtilityMethods.replaceString( trg.getTriggerText(), ";", ";" ) );
                            trg.inheritProperty( JdapiTypes.TRIGGER_TEXT_PTID );


                            * Reattaches Libraries.
                            JdapiIterator libraries= getFormModule().getAttachedLibraries();
                            while(libraries.hasNext()) {
                            AttachedLibrary atachedLibrary=(AttachedLibrary) libraries.next();
                            public void fixAttachedLibraries() {


                            Michael Hitrik
                            • 11. Re: FMB size shrinks dramatically
                              mhitrik wrote:<br>
                              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)?

                              • 12. Re: FMB size shrinks dramatically
                                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.
                                • 13. Re: FMB size shrinks dramatically
                                  Thanks, Jan. Can you explain how I would apply Mickael H's posted code to cause the Forms Builder to modify the fmb file? I have no experience with JDAPI.
                                  • 14. Re: FMB size shrinks dramatically
                                    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.
                                    1 2 Previous Next