Re: Using LOV's in query-only mode

Peter,

[Quoted] 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.

[Quoted] 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 Tue Jul 01 1997 - 00:00:00 CEST