Re: One-to-One Relationships in FORMS

Ed,

A master-detail isn't really appropriate.

Use a single block, with Post-Query and On-Insert/Update/Delete triggers for the LONG item.
Don't forget that a change to a control item does not affect the Record Status, so if the LONG is the only thing that changes then you will need to force the Form to recognise it at runtime.

For example, in the LONG's When-Validate-Item trigger: IF :System.Mode <> 'QUERY'
THEN
  /* Ignore when fired in Post-Query. */   IF :System.Record_Status = 'QUERY'
  THEN
    /* If not already set... */
    Set_Record_Property(:System.Cursor_Record, 'block-name', STATUS, CHANGED);
END IF; Also useful is Get_Item_Property('item-name', DATABASE_VALUE), if you want to make the I/U/D conditional (ie. don't bother if it hasn't changed). You will certainly need it if you don't insert a row when the LONG is NULL.

I wouldn't bother with a view unless your version of the database supports I/U/D on the view.

Ed Jennings <jenningse_at_mindspring.com> wrote in article <34F4A2A1.42C9_at_mindspring.com>...
> I have two tables that have a one-to-one relationship.
> The first table has 14 columns, one of which is a foreign
> key to the second table. The second table has only two columns,
> the primary key and a LONG column. The only reason there are
> two tables is the LONG column. It gets appended to periodically
> and I want to isolate the main table from the chaining.
>
> With that said, FORMS doesn't appear to handle this situation
> very well. If I use a MASTER/DETAIL relationship between
> two blocks, I am unable to simply insert via the FORM as if it
> was one big table. It appears that the MASTER/DETAIL functionality
> of FORMS assumes a master table with a one-to-many relationship to
> the detail table. Further, it assumes you will be updating/inserting
> on only one of the blocks at a time.
>
> I want my FORM to appear to be one logical entity. I want to enter
> data into both blocks and be able to query, insert, update, and
> delete from this form. Is the built-in master/detail functions
> more trouble than they're worth given this scenario? Should I stick
> to one block and use triggers to maintain the second table? This can't
> be that uncommon a situation. Can someone provide guidance on
> how to attack this problem? I have about 9 more FORMS that will
> behave similarly, but with different tables?
>
> Any/All suggestions are welcome.
>
>
> TIA
> Ed Jennings
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> jenningse_at_mindspring.com
>
>
Received on Fri Feb 27 1998 - 00:00:00 CET