--- In IBObjects@y..., Geoff Worboys <geoff@t...> wrote:

> > But it is logical for IBO to revert the value of the field back to
> > the value specified in the DefaultValues. Why would IBO set the
> > field to NULL when I have explicitly told IBO (via the

DefaultValues

> > entry) that I want this field to be 0 as the default?
>
> My expectation is that delete should clear, remove, get rid of,
> destroy, zap etc etc. In none of these do you see the words:
> "set some arbitrary default value".

It's not 'some arbitrary value'... its the value that I have
specified to initialize that field. And initializing a field can
occur outside an insert.

> And possibly more importantly: Altering this behaviour now would
> break existing production applications - including mine!
>
> Default values are used when inserting a record (but then I think
> that has already been mentioned). Any other behaviour you need to

Yes, that is the normal case. But IBO 'owns' the DefaultValues list
and can use it however it sees fit. What you are really saying is
that 'IBO has decided that DefaultValues is to be only used on
inserts'. I fail to see why IBO can't expand its use of this list to
include this situation. IMO, it makes sense that the DefaultValues
entry is to be accessed whenever IBO needs a default value for that
field regardless of whether its on an insert or on a re-
initialization of a field.

> > This characteristic means that if the user inserts and doesn't
> > select a lookup-entry the field will be stored as a 0 no

problems,

> > but if the user inserts, then selects a lookup-entry, then hits
> > DEL, a Access Violation is generated. This doesn't make sense and
> > is inconsistent.
>
> An access violation? Where from? Whats the call-stack?

I'm sorry... Its a EIB_DatasetError exception as follows:
Project nnn.exe raised exception class EIB_DatasetError with
message 'OUTCOMEKEY is a required field'. ...

Call stack:
CheckRequiredFields(...)
SysPost(...)
...

Sorry about that, but it doesn't defeat the message. Although I can
use the REQUIRED column attribute, it still doesn't diminish the
inconsistency mentioned above.

This is not an earth-shattering issue (since I have a work-around)
but one where I felt there was inconsistency.