Re: Don't save block on commit_form

From: Neville Sweet <sweet.neville.nj_at_bhp.com.au>
Date: 1997/11/07
Message-ID: <01bceb3e$9aa90880$d33c1286_at_itwol-pc3963.itwol.bhp.com.au>#1/1


Mark,

To stop Forms attempting to save the first two blocks, try: Set_Record_Property(record-no, block-name, QUERY_STATUS);

If necessary, to obtain 'record-no' an option is to use: to_number(Get_Block_Property(block-name, CURRENT_RECORD));

The status must be reset after populating the lists. This problem wouldn't arise if the items are in control blocks rather than base table blocks. If you don't need Enter-Query functionality then maybe this is an alternative.

Mark Parssey <markpa_at_delm.tas.gov.au> wrote in article <01bcea66$95dd3fc0$ad0b6d93_at_l8ip173.delm.tas.gov.au>...
> I have a form with 3 blocks on it. The first 2 blocks are really just to
> get valid values from the db to build entries for the 3rd table, they
 both
> contain a single list item (as a combo box).
>
> I found I needed to have them as Base Table Items for the blocks as
> otherwise when I ran my create_record code the items from the combox
 boxes
> were cleared out.
>
> Unfortunately the second block utilises a view across 2 tables.
>
> When I commit_form to save the new records in the third block it also
> attempts to save the values in the first 2 blocks. It will not save with
 a
> view such as I have and I am unable to insert the new values.
>
> Either, how can I prevent commit_form "saving" first 2 blocks or how can
 I
> stop combo boxes from loosing data.
>
> I may well have approached this is in a ridiculous manner and any
> suggestions on a better approach are welcome.
Received on Fri Nov 07 1997 - 00:00:00 CET

Original text of this message