--- In IBObjects@y..., "Marco Menardi" <mmenaz@l...> wrote:

> Well, you are right in what you say, but, only with things

organized

> like yours.
> I don't full understand the logic of your application.
> In similar circumstances, I let the field having the NULL value,

that

> means "no key is here to link to a lookup table". You, on the
> contrary, want to force values have 0 in this case (maybe because

null

> are hard to manage?).
> A part from adding code to the client side, you can just put

as "non

> required" the field attribute, and force the 0 value in

insert/update

> triggers in the database.

But this means that I have to write code for every LookupCombo key-
field in every trigger to force this value to 0 if its NULL. This is
the same as having all the code in the BeforePost events which is
alot of work, and can result in alot of bugs.
Its much easier for IBO to use the DefaultValue specified for that
field. When you think about it, it is wrong for IBO to take a
default action which is not configurable by the developer. I have
told IBO that, in the absence of a real value, I want that key-field
to be 0, and IBO should honour that when the user hits the DEL
button on the LookupCombo.

> If your modifications were included, how can the user set the

field to

> null? (canc will set to a default value...)

But I would never want my key-fields to be NULL. I use Generators
for all my keys so storing a NULL into a integer field is
semantically incorrect. NULL is not a proper integer value.

> Put a table of people and a field of "favourite book" that lookups
> onto the books table. The default value is the the most lended

book of

> the library.
> If a person has no "favourite book" you have to set the field to

null.

> It would be really bad having a "fake" book with the title "NO

ONE" in

> the books table...
> How would you solve this?

I use the DefaultValue KEYVALUE=0. This means that no masterkey
matches this value so no 'favourite book' is displayed.

Eric.