Re: Query only form...Help!

In article <1tbim1$elf_at_gaia.ucs.orst.edu> mickel_at_OES.ORST.EDU writes:

>In article <1993May17.065242.21984_at_uws.EDU.AU> roleary@st.nepean.uws.edu.au
> (Rocqueforte OLeary) writes:
>>G'day,
>>I have a small problem with Forms V.3.0. I want to create a
>>query only form for my users. Now, I call the form using
>>call_query, which is fine, but when the users press [exit],
>>the form drops out of query mode and into edit mode. Agh!!!
>>I've made the fields non-updatable, but I'd rather have it
>>where they press [exit] and they return to the menu (i.e.
>>they don't get presented with the question "Do you wish to
>>commit changes?"). Help with this would be much appreicated.
>>Cheers,
>>--
>> ,-_|\ *********** Rocqueforte Daemaen Alexander O'Leary ***********
>> / \ B.App.Sci.(Comp),BPFH,Uni. Of Western Sydney,Nepean,Australia
>> \_.--_/ E-Mail: roleary_at_st.nepean.uws.edu.au Work Phone: 047 360 773
>> o "Don't ask me how it works or I'll whimper"
>
>There are two options as I see it:
>
>0. Have the base table actually be a view. This way, even if you set the form
> fields to the view fields, the properties of the view hold, one of which is
> that they are "view-data-only" tables.

  Why should a view be 'view-only' it is certainly possible to update views based on single tables. I sometimes use it to implement sub-types

>
>1. Disable the "Key-Commit" trigger, as well as any trigger having to do with
> insert, update, or deletes. The "Key-Commit" trigger contains the code for
> making commits, so it would not be hard to substitute code that tells the
> user they can't do this operation (we implement that on some of our forms
> here). I don't like this option because you have to make sure that all
> triggers do not update or delete information from the database. Most of
> our operators are not computer operators, so chances of mistakes that
> result in data inconsistency are greater.
>

 Seems a bigger pain than EXIT_FORM(NO_VALIDATE), or am i missing something.

-- 
tina C London