Re: Using LOV's in query-only mode

[Quoted] When you use the LOV in 'ENTER-QUERY' mode it will not change the :SYSTEM.FORM_STATUS. What's probably changing the :SYSTEM.FORM_STATUS [Quoted] is a column getting populated or changed in a trigger. Usually a POST_QUERY trigger.

Steve

Ian C. Sellers wrote:
>
> Peter,
>
> Thanks for the response. I'm clearly not explaining myself well, but
> let me try once more and I'll keep it short. The problem as I see it is
> with the Forms45 default query-by-example functionality.
>
> Basically, Forms45 changes :system.form_status to 'CHANGED' when you
> return an item from a LOV to a base-table item. Therefore, even if the
> form is in 'QUERY-ONLY' mode, it executes the query, performs it
> properly, and then, after it queries, it tries to commit the
> LOV-returned item, although it's not allowed to. If you tell it "no" at
> this point, it functions exactly the way I require, but I cannot
> suppress this message, nor am I allowed to modify the value of
> system.form_status in a post query trigger to prevent it attempting to
> commit.
>
> I don't have any funny triggers, and I've tried (by an earlier
> suggestion) attaching the LOV to a non-base-table item, then setting a
> default where clause for the block. This works, but is messy and would
> force my users to include this field in every query, even if they didn't
> want to include that as query-criteria.
>
> And re: "My guess is, if you query without using the LOV you get the
> same problem?", the answer is no. If you type a number in the
> :building_permit.asr_sub_number item, I guess the form realizes that the
> field is being populated in 'enter-query' mode solely for purposes of
> finding matching data, and not to insert or change a row. It only tries
> to commit if you return the number to that item from the LOV record
> group.
>
> Thanks for your brain-energy.
>
> -Ian
>
> Peter H. Larsen wrote:
>
> > Hi Ian,
> >
> > It sounds like ither the :lu_name or :asr_sub_number is a base-table
> > field? First of all, a simple tip is to ALWAYS prefix your
> > identifiers
> > with blocknames - you'll be praised when you later don't have to walk
> > through hundres of lines of code to find and fix ambigiously defined
> > items.
> >
> > Next you'll want to look into your post-query trigger. That might be
> > populating forriegnkeys into base-table items. Or what is the most
> > common error -you have an when-validate-item trigger on a
> > non-base-table
> > item that modifies basetable items when it fires. Non-base-table items
> >
> > ALWAYS fire when changed - that includes QUERY-MODE. You usually want
> > to
> > test for :SYSTEM.MODE != 'QUERY' in your when-validate-item when using
> >
> > it on a non-base-table item.
> >
> > The above situation is what usually causes updates of base-table items
> >
> > in a query situation which results in you problem. I don't think it h
> > as
> > to do with LOV if it happens when you QUERY data. My guess is, if you
> > query without using the LOV you get the same problem?
> >
> > - Peter H. Larsen
> >
> > Ian C. Sellers wrote:
> >
> > > I'm really stuck! Please help.
> > >
> > > I've made a F45 form with a text item that can call a LOV to
 populate
> > > itself with a number corresponding to a subdivision name in another
> > > table -- you pick the sub name from the list, and the form populates
 

> > > the
> > > field with a representative number. It's all in query-only mode to
> > > this
> > > point. The record group for the LOV is created by
> > >
> > > SELECT lu_name, lu_num
> > > INTO :lu_name, :asr_sub_number --(f.k. to lu_num - represents subdiv
 

> > > name)
> > > FROM lu_subs;
> > >
> > > This all works fine - remember it's a query-only form - set at the
> > > block
> > > properties level. The problem is, after you retrieve the LOV, pick
> > > one,
> > > and execute the query, it populates the all the fields from the
 first
> > > row of the queried group, then as the form leaves "query-only' mode
> > > after the query it displays "Would you like to Commit to the changes
 

> > > you
> > > have made?" I didn't change anything! Tell it "No" and everything is
 

> > > fine.
> > >
> > > I don't understand why this message appears - if you do tell it
 "Yes,"
> > >
> > > to commit, it returns an error saying it can't insert record --
 which
> > > is
> > > logical as the form is restricted from inserting, updating, or
> > > deleting
> > > in the block properties. After that it will continue to show this
> > > "Would you like to Commit" message until I finally tell it "No."
> > >
> > > How can I suppress this message? I'm guessing since I opened an
> > > implicit cursor with the select into, that it assumes something was
> > > changed. I can't rollback because Forms treats that as a clear_form
 

> > > --
> > > and I would lose all my queried info. I don't want to commit to
> > > nothing
> > > either - simply out of principle if nothing else!
> > >
> > > TIA,
> > > -Ian
Received on Wed Jul 02 1997 - 00:00:00 CEST