Re: post-query & when-validate-item triggers

From: GLucas4189 <glucas4189_at_aol.com>
Date: 7 Nov 1998 11:41:28 GMT
Message-ID: <19981107064128.15592.00000422_at_ng43.aol.com>


Hi,

It is not the fact that nbt items are changed which causes a base table update, it is the fact that there may be LOVS VALIDATION on a nbt, which gets reflected back to a base table item mapped within the LOVS iteself. This occurs of course when the base table item is already populated from the query and is then marked as changed because the LOVS attached to the nbt has retrieved a second value in to the base table item.

In addition validation triggers like WHEN-VALIDATE-ITEM, that are written against nbt items will fire. If the validation trigger populates a base table item value in another block, as I have seen with some code (admittedly dodgy ! ), then it will fire a base table update in that other block, which means that the SET_RECORD_STATUS - clause, in the previous post is not necessarily sufficient. The solution is to introduce as well as this a flag which is set at the beginning of the POST-QUERY trigger, and unset at the end. For example :-

POST-QUERY
:blk.hi_query_flag := 'Y';

code etc...

:blk.hi_query_flag := null;

On your corresponding WHEN-VALIDATE-ITEM triggers, you would the code as follows :

BEGIN if :blk.hi_query_flag is null then
:blk2.value := :blk1.value;

end if;

END; Don't recommend these kind of assignments anyway...but after debugging a few, this seems to be a solution...

In addition ensure that LOVS_VALIDATION is set to false in your field properties, or set to false by the use of the SET_ITEM_PROPERTY(:system.cursor_field, LOVS_VALIDATION, PROPERTY_FALSE) etc...

You could code this automatically by writing an ON-FETCH trigger which would loop around all records in the block and perform the SET_ITEM_PROPERTY(:system.cursor_field, LOVS_VALIDATION, PROPERTY_FALSE) etc... and then the FETCH_RECORDS built in..

If you wanted to automatically switch on LOVS_VALIDATION in normal processing you could write a form level PRE_TEXT-ITEM trigger :-

PRE-TEXT-ITEM if field_lovs ( some function to find it if is a LOVS field ) set_item_property(:system.cursor_item, LOVS_VALIDATION, PROPERTY_TRUE) end if;

and then switch it off a POST-TEXT-ITEM trigger :-

BEGIN
if field _lovs then

set_item_property(:system.cursor_item, LOVS_VALIDATION, PROPERTY_FALSE)

end if;

Be careful with internal navigation also, because even if the user does not navigate to a field, but you do programmatically, the LOVS_VALIDATION settings will fire due to PRE-TEXT-ITEM above. In this case, for internal navigation, is it is advisible to set the LOVS properties of the fields to null, to ensure that it cannot fire, and then reset it afterwards, after your internal navigation.

Hope this helps...

Graham

Actually, thinking about it.. you could write a form level POST-QUERY trigger, which would have

set_record_property(:system.cursor_block,RECORD_STATUS, QUERY) etc..

But then, you would have to ensure that every block has the execution hirerarchy set to 'before'... so that the form level POST-QUERY trigger would fire.

But you would still need to watch out for those LOVS_VALIDATION settings for internal navigation... Received on Sat Nov 07 1998 - 12:41:28 CET

Original text of this message