I had a related question, not life or death, but this is still really bugging me!
I tried the fix for the huge file size of replacing all the ";" with another ";" and it works perfectly. :)
But what is confusing me is that we have been using Forms 6 for a while (at least 2 years) when suddenly the size of the FMB files started balooning.
We had been using forms for several years and it NEVER did that. So my question is: why has it suddenly started doing this? It started acting like this all of a sudden and now we cannot get it to go back to its original behaviour!
Could some setting have been changed? What did we do to cause it to change its compile strategy suddenly ?
PS. I am certain that Forms did change its compile strategy because we have backups from the past and when we recover those archived files and recompile them they suddenly get larger. :-| And we know that these were compiled because we archive the FMB files along with their corresponding FMX files. :)
There is no switch that I know of -- if there were, we would sure be using it here!
Have you started using a PLL library? (Not sure if this would have an affect, but it makes me wonder.)
The other thing: whoever is making the last change to the .fmb and saving it... in the past, were they making the change and saving from the Forms Builder while disconnected from the server? When disconnected, any procedure and trigger that makes SQL call to the server will remain uncompiled, so saving the form in that state will render it uncompiled.
If they are now working while Forms Builder is logged in, those procedures and triggers will stay compiled, and the .fmb will be larger.
Are you doing a batch compile with the Compile_All=Yes parameter? That updates the .fmb source, too.
Many of those were my own and I know that I mostly just use the "CTL-R" or "CTL-Shift-K" command to just execute the forms from within Form Builder. And then when I am finished with the FMB file I just exit Form Builder whereupon it askes me if I want to save and I say say "yes". So those forms, right from the beginning, have been saved:
1) after compile
2) after compile while connected to the database (I never do any work while un-connected to the database).
Also I tested that and even when doing a recompile while not connected to the database a very comparable gain in file size happens.
Also, we have several forms which do not access the database at all (they simply perform some display using parameters that are passed to them) and these forms also exhibit the same anomaly.
Finally, we did start using some PLL files but even forms which do not inherit or make use of these PLL files (as far as I can tell) are having this problem. I even hid the PLL files (by changing the directory name) and shut down the database and still got this problem.
Also the problem is also happening in files which were recompiled AFTER we started using PLL files with those forms. In other words, we take a pristine form, from a backup CD, which was developed using PLLs and merely recompile, without making changes, and where the link to the PLL files is broken because I have moved the PLL files and BAM!! the file size inflates anyways.
And remember even brain dead forms with only one non-database block are having this problem (these are banner and messege forms).
The mushrooming file size has been going on since forms 4.5, but there was no easy way back then to find all / change all ; in a form. Back then, it was a matter of creating a brand new form and dragging everything from the old one into the new one. That was my "clean-up method" back then,
If there was ever an automatic way to compress the fmb automatically, you may have stumbled across it, but there is nobody around who can tell us what it is.
If you can ever identify the series of events, I would sure like to know what they are.
188.8.131.52.2 ??? Why are you working with such old Forms?
That is barely Forms 6. Forms 6i is 6.0.8, and the highest patch (18) brings it to 184.108.40.206.0
And Oracle support for Forms 6 is almost gone. Why don't you at least upgrade to the last Client/Server version of Forms? It won't resolve the mushrooming issue, but at least you will be up with the rest of the Forms 6i people.
Well: we have been thinking about upgrade in the near future but we have been worried about that which is why I have been running some checks on the old forms to find out if there are any issues related to that.
Basically I have been verifying that everything compiles properly on the old code and weeding out some dead wood preparatory to any further steps.
And that is how we turned up this mushrooming file size issue. :0
You know: we want to make sure all is OK now before we upgrade so that when we do upgrade and encounter issues we can pinpoint that as being an upgrade issue rather than being uncertain what the problem is.
So that's another reason I am wondering if there is a way to look at the source FMB file and discover which version of FORM BUILDER it was created on. :)
Is there a way? do those strings I mentioned last post contain any useful info?
I never went into the .fmb files and snooped around, so I don't know, and I have not seen anything on this message board to that effect, either.
I believe I have seen some minor issues with forms created in 4.5 on a Mac with the color palette being slightly different. But that was all. If you are already on 6.0.5, moving to 6.0.8 should not cause any trouble. If you leave Client/Server and go to Web Forms, there could be some issues.