My greatest wish belonging to Forms: Stability!!!

Question

Working with forms result often in a FRM-92101 (An unexpected server failure ...)
I'm solving this problem with an OK-Button in an alert at the coding where the error happens.
And the miracle is: Forms is working whithout error.
After removing the alert the next miracle: Forms is working with no error?!
That's very angry for me and my customers.
I'm working with:
Java Plug-in 1.5.0_06
Forms 10.1.2.0.2
Application Server 10.1.2.0.2
Best regards from
Franz

Answer 1

Thomas Morgan wrote:
We recently upgraded our application to 10g and sporadically we see some erratic behaviors in the application (i.e. freezes, queries that normally run in under a second take several minutes, etc). Do you have any opinion as to whether the fact that we store and compile in unix the fat fmb as you so accurately describe, may have a contribution into the erratic behavior or do you think this is an exclusively developer inconvenience issue by having to work with larger files?
I agree with Jan that these things need to be addressed individually. I am pretty sure it has nothing to do with fat fmbs. First thing I would look at with the seconds to minutes query problem: Is the form affected by rows locked by another user? Forms that accidentally lock rows when they are queried will cause a second user querying the same data with the same form to experience a lockup until the first user commits or rolls back. Of course that would have happened the same way with client/server forms.
Thomas Morgan wrote:
Would you care to elaborate on this? Were you still referring to the inconvenience to your developers of having to ftp the fat file?
The problem was this: During display processing, the forms called a stored procedure that returned some numbers to display, so the parameters were "number". Sometimes the form would display -0, or ##### (negative zero, or a number too large for the format mask). This happened with the forms stored containing compiled code (the fat fmb), even though we would click the Ctrl-T to compile the form (note this was NOT the shift-ctrl-K to "compile all"). Once we did the replace all semicolon process, the problem went away.
Note that the stored procedures were standalone -- not part of any package.
user505142: (Can't you get a real name to display? :-)
Although doing a Compile PL/SQL All won't reduce the physical size of the FMB, it does seem to remedy the compiler bug, and eliminates the need to repair referencing.
Yes, I agree. In that situation, I would NOT do the semicolon-semicolon replace all.
And your "forgotten holdover" theory sounds quite likely. Storing fmbs in the database along with compiled code might have been the beginning steps toward facilitating forms to be automatically recompiled whenever any table or package they used was changed. That would have been a nice feature.