At 02:42 AM 04-10-02 +0000, you wrote:

>Hello,
>
> (BCB6-SP2, IBO-4.2Hf, FB-1.0, Enh2.1.2)
>
> I have a LookupCombo, which when I hit 'DEL' to delete the entry in
>the control, it sets the underlying field to NULL. I don't think this
>is correct... I feel it should set the field to the value stored in
>the DefaultValues.

Defaults are applied to inserted rows only, so they won't kick in if you
clear a value in an existing row.

If you don't want Field.Clear behaviour from the DEL key then you can
intercept the keystroke and replace it with whatever you want, e.g. restore
its original value by referring to the OldValues object (a TIB_Row); or
explicitly read the DefaultValues array if you want to access it in edit
mode...

> What's happening with me is that I hit 'DEL' and it sets the field
>value to NULL, then the 'FIELDXX is a required field' exception is
>being generated. So to circumvent this I am checking the field value
>in the BeforePost to see if it is NULL, and if so, setting it to 0
>(my IB field attributes is INTEGER DEFAULT 0 NOT NULL).

Mistaken expectation...IB/Fb defaults have never been available to
updates. The usual way to deal with illegal key changes is to write a
Before Update trigger for the table, using the OLD context variable to
reset the value if the NEW value doesn't match it. But, of course, your
client app doesn't know about any triggers so this won't cure the problem
you have created in your app.

Why are you giving the user edit access to your lookup table anyway? It
seems a pretty unstable arrangement...

> I shouldn't
>have to do this on every BeforePost that has a LookupCombo... IBO
>should really do it (since it knows what its default value is.)

For Inserts, IBO will know about database defaults in one of two ways:

1) You set GetServerDefaults true. This bring the defaults over to a
client-side array (for inserts only). The downside is that it makes
opening your query rather expensive.

2) You go into the Fields Editor and set the default value explicitly as a
Column Attribute. (You can also do this globally by setting ALL of your
column defaults explicitly in the DefaultValues property. At this level
each column needs a table identifier.

If you don't do either of these, IBO has no way of knowing about your
defaults at all.

> Unfortunately, I don't have Delphi so changing the underlying code
>is difficult but the current logic for the assignment is below:
>
>procedure SysUpdateKeyLinksData (IBA_Dataset.IMP)
>...
> if tmpCanModifyKeyLinkField then
> KeyDataset.FieldByName( KeyLinks.IndexValues[ ii ] ).Assign(
> FieldByName( KeyLinks.IndexNames[ ii ] ));

This logic applies to KeyLinks - the values that are stored in the
KeyValues array. You shouldn't mess around with it if you are using
TIB_LookupCombo "as designed", since KeyLinks determines the
Keysource-Lookup relationship for this particular setup....another reason
not to make your lookup dataset editable.

Helen