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

> Well, there is some misunderstanding...
> - NULL is a state, it means "unknown"
> - 0 is an arbitrary value, that you interprete as "no lookup

linked"

> - Canc in LookupCombo is the action of setting the underlying

field to

> null
>
> If you want your application with 0 that means "null", you have to
> change the behaviour of a lot of things...

No, I don't want 0 to mean NULL; I want IBO to honour the
DefaultValues value... if I specify a DefaultValues entry of
KEYVALUE=NULL, or KEYVALUE=100, or KEYVALUE=Some String, or
KEYVALUE=0, I want it to take that value on a field reset. And if I
have no associated DefaultValues entry, then IBO is free to assign a
NULL to that field.

>
> Well, if you enter a field in IB_Edit, and you press "canc" while

it's

> highlighted, the field is blanked, not set to default value, but

this

> seems reasonable to me.

But the DefaultValues should apply here, too. If I have a VARCHAR
IB_Edit BOOKNAME with a DefaultValue BOOKNAME=No Choice, then if I
cancel then I want IBO to re-enter the string 'No Choice'.

> seems reasonable to me. And so reasonable seems the Canc in
> LooupCombo. If you want a property for every possible use of a
> control, you will end up with a 1,000 property control that is

unusable ;)

Nope. I want the standard DefaultValues property to be applied
consistently regardless of the control's use.

> I don't use default values in lookup fields, this is not a common

use

> of lookup fields. Lookup fields should have two possoble "sets" of

values:

> a) null -> no lookup
> b) foreign key value
> that's all...

This is what Geoff was talking about... 'sets', and this is not
the issue... its what is physically stored in the keyfield to denote
an empty set... and I want to be the one that specifies that, not
IBO.

> > 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.
>
> That's not the meaning of Default values. It's something that is a
> default, not a "basic state". It's wrong, if you want to see

something

> wrong, that LookupCombo gives no visual clue that it has a value in
> the field (0) that has no corresponding in the lookup table.
> Just today I had a nasty bug because I deleted some rows from the
> lookup dataset, and the "base" table was not "cascade" updated.
> LookupCombo presented an empty field, so I thought that a NULL

field

> was there, not a non matching one...
>
> >
> > > 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.
>
> So you use LookupCombo to "build" your primary key in the table?

i.e.

> the primary key is a composite key, with some fields that have

values

> taken from lookup tables? mmmmm....
> You could have an generator to build the unique primary key of that
> table, and a "unique" index upon the fields that now are composing

the

> primary key... so NULL would be allowed.
>
> > 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.
>
> In SQL database, you have NULL as "unknown", so it's semantically

very

> correct in a database field :)

No its not. Having a NULL in a integral-type field in Interbase
generates all sorts of problems. Try adding a integral field which
has a NULL value to another integral field... The answer is that you
will get NULL. So NULL + 5 = NULL, whereas (obviously) 0 + 5 = 5.

>
> > I use the DefaultValue KEYVALUE=0. This means that no

masterkey

> > matches this value so no 'favourite book' is displayed.
>
> Well, tomorrow I will insert a book with 0 as primary key. Ok, you

can

> avoid it, but you have to write code in the triggers, that you

don't

> like to ;)

I love triggers! I have triggers to do everything under the sun. I
just don't want to do client-side validation on the server.

>
> Eric, I understand your fristration in this conversation, it's like
> when I ask for some "obvious" IBO enhancements and someone tells me
> that it's not desiderable... I think "how can that **** don't see

how

> usefull it would be???"

I like the way you put this! But I am not asking for an
enhancement... just asking that the INSERT statement that IBO
generates is consistent regardless of what the user does.

Eric.