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?

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.

Malcolm Dew-Jones (yf110 (AT) vtn1 (DOT) 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.


--

Malcolm Dew-Jones (yf110 (AT) vtn1 (DOT) 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.


--

Malcolm Dew-Jones (yf110 (AT) vtn1 (DOT) 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.


--

Malcolm Dew-Jones (yf110 (AT) vtn1 (DOT) 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.


--