Re: Using LOV's in query-only mode

Ian C. Sellers wrote:

Hi Ian,
Sorry for replying so late, I havn't had access to newsgroups for a few days. I'm cutting down our thread qoute for simplicity sake.

I'm not sure I understand what it is you're trying to do. What you have is a code and a text. The base table contains the code and you have a lookup table that has the text? You then want LOV to return the text?

1. Are you using redundant entry of the text field, so it's represented both in the lookup table and the base table? If so, there is your problem.
2. The code is the base-table item and the text is not. Your LOV returns the code to the base-field and text to the non-base field?
3. LOV has nothing to do with Query. It's to be executed manually by the user. So I ask again, if you don't use the LOV when you query, do you have the same problems?
4. Are you refering your childblock from your master block with an assignment? If so, that's a NO-NO. (the other way around it's okay).

Your usual standard design calls for a post-query and when-validate-item triggers construct to synchronize your code to the text field, either by query or by entry. But as you don't use entry (QUERY only form) I'm not sure what it IS you're doing?

Or is the case like this:

master-block with LOV
detail block that queries depended on master-block

if so, why is the master-block a base-table block? You don't need a base-table item to condition your details block. You can either user WHERE or just the COPY VALUE FROM property just as you pointed to a base-field item. It will join the master and detail block together without problems.

In short: If your query is controlled by a user-entered value, that is NOT done in ENTER-QUERY mode you use a non-basetable block. You can assign values in this block using QUERY-ONLY mode. And you can refer to non-basetable items in master/detail forms just as easy as if it was an base-table item. There is no difference in that regard.

If you're not using WHERE clauses now to group your condition LOV with the details block what are you doing that's not possible with non-basetable items?

Hope this help - otherwise email me your basic formstructure and let me have a look at it again (not the fmb file, just a summery of the construction).

• Peter H. Larsen

> 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
>
Received on Fri Jul 04 1997 - 00:00:00 CEST