> 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.

It is arbitrary when used out of (the expected) context.

>> 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.

IBO did not decide this, it is consistent with the way that IB/FB
(and AFAIK all SQL client/server systems) operate. That is; the
accepted definition of "default" in this context is:

the value used during an insert, when no input is specified.

Note that, at the server, this even goes to the extent that you can
explicitly try to insert NULL. That is; If you specify the field
at all during insert, the corresponding value (even it that value
is null) will be used and any defined default will be ignored.


IBO has the DefaultValues list, it is publically accessible. If
you want some specific behaviour in your application either:
- provide appropriate changes in the app
- derive your own control class with the desired behaviour

If you check the code in IBC_Label.pas:
function IsIBColumnMandatory
you will see where I use the DefaultValues and Required attributes
to determine whether a particular field should be considered
mandatory for purposes of the AutoLabel display. Regrettably
the GetColAttrTxt method had to be duplicated from IBC_Statement,
we really should do something about making a single copy of that
method publically available somewhere.

> 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.

Its all entirely consistent - the user tried to post a NULL value
to a required field.

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

Just as a side note...

Even if I did happen to agree with you that this was a good idea
(and I guess a property could be setup to provide this capability
as an option), there are complications...

- Lookups correspond to possibly multiple fields.
- Lookup datasets can have other dependencies (eg master/detail)
- The foreign key value changes are generally driven by the
lookup dataset (during edit modes) rather than by the value
of the field.
- Lookups often (usually?) use surrogate key values, as such
setting up defaults for these values can be error prone

All these things make the situation rather more difficult to code
a solution on a generic basis. I know because I have an app that
tries to provide a default lookup search value (separate issue,
its not using DefaultValues) and it took quite a lot of work to
get it working smoothly.


--
Geoff Worboys
Telesis Computing