Wirt:

So why is everyone trying to make exceptions to this behavior.  Any exceptions
will eventually create a problem for someone who either does not know the
exceptions or has plainly forgotten them.

Lets propose to csy that:
1.  If the flag is set to off,  a critical item can not be updated without
hardcoding the DBDELETE/DBPUT logic.
2.  If the flag is set to on,
     a.  The CIUPDATE will verify the CI fields for the existence of any
cross-references (if any), and report errors.
     b.  Internally perform an DBDELETE and DBPUT of the record and report the
condition code.

     The condition code might return success with a critical item change or
success with no critical items changes.

PERIOD.

I would feel secure if this behavior becomes reality, otherwise I will keep coding
the DEDELETE/DBPUT logic.

Olav.

Wirt Atmar wrote:

> Olav writes:
>
> > I would suggest that if CIUPDATE flag is set to on, then the behavior of the
> >  CIUPDATE should be exactly like a DBDELETE/DBPUT of the record.
>
> That is exactly the position that I am advocating too.
>
> Wirt Atmar
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *