Re: Possible Forms 5 bug with LOV and Updating ??

From: Neville Sweet <sweet.neville.nj_at_bhp.com.au.no_junk_email>
Date: Thu, 4 Nov 1999 17:57:37 +1100
Message-ID: <7vrath$84032_at_atbhp.corpmel.bhp.com.au>


Hi Robert,

Update_Allowed prevents the operator from changing the item, but does not stop you from setting it programmatically. Being a return item in an LOV is not equated by Forms as being set by the operator. Why don't you set the analyte name to be update_allowed = No, if not permanently then programmatically via Set_Item_Property ? The property applies equally to nonbase-table items, despite what Help might suggest. If that's not possible then you could create a second LOV, minus the analyte return item, which is attached programmatically with Set_Item_Property(item,LOV_NAME).

Regards,
Neville.

rtproffitt_at_my-deja.com wrote in message <7vo542$uho$1_at_nnrp1.deja.com>...
>Hello,
>
>I am getting a situation in Forms 5 where the system is
>generating an UPDATE statement referencing an item
>whose property has been set to UPDATE allowed = NO.
>This happens because an LOV is populating the
>item, even though is it marked as updateable=no.
>
>Has anyone else seen this behavior? Possible bug?
>If I make the entire block update=no, then the LOV
>fails to populate the item (correctly). However,
>this solution is unacceptable in my circumstance,
>since another data item must be updateable in the
>same block.
>
>Here are some details.
>
>Data block X
> update changed columns only = yes
>
> Item Analyte
> number 6, mask 999999
> database yes
> query only NO
> insert yes
> update no
>
> When-mouse-click
> do key list values
> Key-ListVal
> If show_lov('mylov') then
> next_item;
> end if; [<= if choice made, go next...]
>
>LOV
> The lov has two items, analyte and analyte name,
> Choice populates both x.analyte and x.analyte_Name.
>
>Results
>1. No typing is allowed in the analyte field (correctly)
>since it is update no.
>
>2. Mouse click or F9 key shows LOV, and choice populates field,
>then Next_item causes save message "do you want to save
>changes". Answering Yes, causes FRM-40509, unable to UPDATE.
>
>3. /help/Display Error show an update statment with the
>Analyte column listed, clearly having circumvented the update=no
>property of the item. v (it so happens that if fails with
>a unique violation...lucky for me...).
Received on Thu Nov 04 1999 - 07:57:37 CET

Original text of this message