Re: FORMS, detecting modes, etc

Malcolm Dew-Jones (yf110_at_vtn1.victoria.tc.ca) wrote:
: In Oracle forms (10GR2, though I doubt that makes much difference).

: I am trying to find how to do the following, feedback appreciated.

: A form can be in POST ONLY mode. (COMMIT not allowed).

: Q: how can a form detect it is in POST ONLY mode?

: A form can be in QUERY ONLY mode.

: Q: how can a form detect it is in t QUERY ONLY mode?

 RANT Well, Oracle can be very frustrating sometimes. I'm not a big fan of Oracle Forms, but it can be very easy to make database applications - until you need/want things that should be simple but aren't due to annoying "features" of forms.

In this case I have found dozens (perhaps hundreds) of oracle forum discusions going back for years and years where people are asking exactly this question - how to detect query_only mode. Oracle forms internally obviously has this data available since each form modifies its behaviour due to the mode, but there is apparently no easy way to detect it, just kludgey workarounds, such as trying to write data and trapping the error.

In spite of so many questions over the years, and what would appear to be the simplicity of the change, In metalink Doc ID: Note:118449.1 Last Revision Date: 17-JUN-2008 (i.e. very recent) Oracle says "An enhancement-request regarding this feature is rejected."

They give a work around, which is a procedure with an obvious bug! - forms default behaviour allows a query_only form to call a non_query_only form and it is silently converted into a query_only form - but if you were to use the provided workaround then the global variable flag would be set incorrectly. OK, you could write your own wrapper, but it just illustrates that in fact this problem is not "easily" done - handling these sort of small issues is continually "reinventing the wheel", and is exactly the kind of situation that leads to small but annoying bugs which makes programming forms much more trouble prone than it should be.

Also, routines such as the example wrapper end up creating tightly coupled code with numerous unnecessary interdependencies and assumptions, making them unnecessarily hard to debug, and hard to reuse. In the case of the example, 1) a global variable, and 2) the dependency that every single form always uses the custom interface - woe to the app in which a programmer simply does the obvious things and uses Oracles own function CALL_FORM when they need to call a form.

 /RANT
: EXIT_FORM can prompt a user to "SAVE CHANGES?"

: Q: is there a way to control the text of the question?

: (Not the message afterwards that says "records saved", just the
: string used as the question text. The message afterwards is
: seen by ON-MESSAGE/ON-ERROR triggers.)

: Feedback appreciated, thanks.

--