Strange Forms compile problem
Ketil Holden
We are experiencing some strange problems with two of our
application's forms. They are rather large and complex, the .fmb files
are about 3,5 to 4.0 Mb.
Both forms rely on objects from .plls and one other form containing
common elements used in other forms.
Both forms have trouble compiling. The first one (4 megs .fmb and 900K
.fmx) loses about 1 megabyte when saved, and does not work. It takes
the browser with it. Almost 100% of the time the erroneous saving can
be fixed by adding a message() in a function run halfway through the
registration process. The form then "regains" it's correct size, and
works normally.
The other form is 3,5 megs, but the .fmx is only some 300K. This has
suddenly stopped compiling at all. It was fine until recently, but now
it saves wrong all the time, and more often than not pressing the save
button in Form Builder makes it crash without saving, of course
without error messages. This ususally happens if we try to save the
form after compiling it.
The only complaint from Forms Builder throughout this process, is when
opening the "common" form it warns that some d2kwhelp library will be
missed. I cannot find it, and as I understand it relates to some
winhelp stuff - we don't use any winhelp so I figure this should not
be a problem.
The errors evident in the forms when they are run are "no data found"
or thereabouts, or frm-92100 "your connection was interrupted". The
first form also contains the logon form, and will often just not show
up in the browser at all.
Any thoughts?
--
Ketil Holden
Sybrand Bakker
wrote:
>Any thoughts?
>
>
>--
>Ketil Holden
Sure,
never assume anyone in this group to be clairvoyant and *ALWAYS* post
platorm and version info
Sybrand Bakker, Senior Oracle DBA
To reply remove -verwijderdit from my e-mail address
nobody
sysytem.. probably under the oracle home...
Sounds like a .dll problem ,, you need a patch, make sure you do a compile
all. not just a Ctrl T generate
"Ketil Holden" <ke...@softhome.net> wrote in message
news:gk83nvocpgfqo6bqp...@4ax.com...
Ketil Holden
<gooid...@nospam.demon.nl> wrote:
>Sure,
>never assume anyone in this group to be clairvoyant and *ALWAYS* post
>platorm and version info
Whoops, I had a feeling I forgot something.
Forms [32 Bit] Version 6.0.8.21.3 (Production)
Oracle Toolkit Version 6.0.8.21.0 (Production)
I think it is called patch 12
Windows 2000, and the browser is Netscape 4.78.
Actually netscape is unable to terminate properly after running a
bogus form. The window disappears, but it is still lurking in the
process list.
--
Ketil Holden
Ketil Holden
>when it does not compile I bet there is a .dmp file somewhere in the
>sysytem.. probably under the oracle home...
4 actually. What are .dmp - dumps?
>Sounds like a .dll problem ,, you need a patch, make sure you do a compile
>all. not just a Ctrl T generate
I have the patch (12?) that was recommended from Oracle (se above for
actual versions). I do a ctrl-t followed by ctrl-shift-k.
--
Ketil Holden
Ketil Holden
wrote:
>
>We are experiencing some strange problems with two of our
I got this answer on OTN and it actually solved the problem. It didn't
warm me up any further towards Forms that's for sure.
<snip>
Forms fmb files balloon in size when they are compiled because Oracle
stores compiled code inside the fmb. Since some parts of your form are
not compiling, when you save it, the code that is not generated
correctly is left out, so your fmb file changes in size.
We always save our fmb files in their uncompiled state. To do this,
just before saving, and AFTER compiling, do a Program, Find and
Replace, and change all ; to ; and then save without compiling again.
The change marks all program units as uncompiled, and the fmb shrinks
in size. In fact, there were some problems we encountered with PLL
libraries and calling stored procedures that were cleared up once we
started saving the fmb's that way. ...it might help with your trouble.
</snip>
--
Ketil Holden
Daniel Morgan
Also note the most recent patch is 14 and that your browser version is very old and you should be
working with Netscape's latest.
I've been building and running Forms apps for years and suspect based on my experience that your
problems relate to the developers rather than the product.
-- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damo...@x.washington.edu (replace 'x' with a 'u' to reply)
Ketil Holden
<damo...@x.washington.edu> wrote:
>Your posting does not compute. All .FMB files are uncompiled. The
>compiled version is .FMX.
I thought so too, but my observations seem to agree with him. When I
do the s/r madness, the file loses some 1,7Mb. And coincidentally it
starts working.
>Also note the most recent patch is 14
I know, but the folks at oracle recommended 12. I don't know why, I
didn't make the call.
>and that your browser version is
>very old and you should be
>working with Netscape's latest.
Well, somehow the organization has found that Netscape 4.78 is the
best browser for Forms. It has less flickering that IE5 , 5,5 6.0 etc.
All the users use Netscape 4.78, and so the developers do too. It is
not my decision.
I've seen this flickering at an Oracle University course in new
browsers, in quite basic forms. This is not an issue of developers as
far as I can see, but of the product or perhaps the java gui
classes... I think I've seen this in JBuilder too...
>problems relate to the developers rather than the product.
Well, that may be. The application has been buggy and more than one
company has been involved in it's development. Documentation is close
to void, and that arguably speaks for itself.
However, in my defence, as a recently employed maintainer of this
beast, I think, in any product, the save / compile routine should
work flawlessly 11 times out of 10. And referring to patchlevels 14
with regards to such problems probably says something about the
product as well.
--
Ketil Holden
Daniel Morgan
On Thu, 25 Sep 2003 07:00:02 -0700, Daniel Morgan <damo...@x.washington.edu> wrote:Your posting does not compute. All .FMB files are uncompiled. The compiled version is .FMX.I thought so too, but my observations seem to agree with him. When I do the s/r madness, the file loses some 1,7Mb. And coincidentally it starts working.
Also note the most recent patch is 14I know, but the folks at oracle recommended 12. I don't know why, I didn't make the call.
and that your browser version is very old and you should be working with Netscape's latest.Well, somehow the organization has found that Netscape 4.78 is the best browser for Forms. It has less flickering that IE5 , 5,5 6.0 etc. All the users use Netscape 4.78, and so the developers do too. It is not my decision. I've seen this flickering at an Oracle University course in new browsers, in quite basic forms. This is not an issue of developers as far as I can see, but of the product or perhaps the java gui classes... I think I've seen this in JBuilder too...
problems relate to the developers rather than the product.Well, that may be. The application has been buggy and more than one company has been involved in it's development. Documentation is close to void, and that arguably speaks for itself. However, in my defence, as a recently employed maintainer of this beast, I think, in any product, the save / compile routine should work flawlessly 11 times out of 10. And referring to patchlevels 14 with regards to such problems probably says something about the product as well.
and make recommendations. The problems you are experiencing are not the norm.
Ketil Holden
<damo...@x.washington.edu> wrote:
>This isn't a question of opinion but rather one of fact. FMXs are the
>compiled version.
Yes I knew that, but something mysterious happens to the FMB's also. I
don't know what, but it grows if compiled and then saved. So when
somebody comes around and solves it, and claims this is because
compiled code gets stuffed in the source, I am inclined to believe
him...
It sounds strange, it would be like a C-IDE attaching object or
executable files to the source files.
>Perhaps when you asked 14 didn't exist. Download it and test it.
The call was made the day before my original post.
>I was referring to Netscape 7.1. Once again ... download it and test it.
I will, but that is another thing entirely really.
>I'd suggest that your firm consider bringing in a Forms expert for a few
>days to a week to evaluate the beast
>and make recommendations. The problems you are experiencing are not the
>norm.
The thought has crossed my mind... I am glad this is not the norm :-)
--
Ketil Holden
Alex Filonov
> Ketil Holden wrote:
>
> >On Thu, 25 Sep 2003 07:00:02 -0700, Daniel Morgan
> ><damo...@x.washington.edu> wrote:
> >
> >
> >
> >>Your posting does not compute. All .FMB files are uncompiled. The
> >>compiled version is .FMX.
> >>
> >>
> >
> >I thought so too, but my observations seem to agree with him. When I
> >do the s/r madness, the file loses some 1,7Mb. And coincidentally it
> >starts working.
> >
> This isn't a question of opinion but rather one of fact. FMXs are the
> compiled version.
>
True. But .FMB files contain both uncompiled and compiled codes for
PL/SQL objects. Just do a simple test: do a replacement for all units
as recommended in previous post and then generate the form. You'll see
a task bar and lots of messages "Compiling ...". Then regenerate the
form again. You'd barely notice the task bar. Also, you can see cross
reference info for compiled objects, but can't see it for uncompiled
ones.
So yes, to reduce the size of FMB file and get rid of other problems,
just uncompile all PL/SQL units in the form. Same true for PLL libraries.
> --
nimonic
Here is some snips from a closed bug logged about the change in fmb
size:
PCODE CAUSES FORM SIZE TO INCREASE BY 300%
--------------------------------------------------------------------------------
*** 02/11/00 07:45 am
*** PROBLEM DESCRIPTION =================== .
The encoded PL/SQL (PCODE) being saved in the FMB is causing the size
to be be increased by 300%. .
PROBLEM EXPLANATION =================== . You have a form to which you
open in Form Builder. If you do a compile all and then save the fmb,
the pcode (PL/SQL) is saved. This is correct behavior. In prior
releases ie: 4.5, you could convert the fmb to a fmt and then back to
a fmb and the pcode would be removed. This is not happening with the
Forms 6.0 version.
ADDITONAL INFORMATION ===================== . From my understanding,
what we do internally with an FMB as the compiled state changes or
the module is converted between formats doesn't really matter. All
in all, fluctuations in FMB size should not really concern the
customer, however, in this case, it is detrimental to their cost.