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

> It all comes down to what you understand as the meaning

of "default"

> and the meaning of a foreign key value.
>
> At the client the default is the value applied when you first

create

> the record.

Right, my point exactly. If a user clicks on a LookupCombo
selecting a 'favourite book' and then presses DEL, the server has
not been involved upto this point. So when the user first physically
creates the record, the key-value will be either some foreign-key,
or the DefaultValue or NULL if the user has pressed DEL. This is
inconsistent and wrong.

>
> At the server the defined default is ONLY applied if you do not
> specify a value on insert (if you specify NULL it is accepted).

But the server has nothing to do with this... this is purely a
case of how IBO generates the INSERT statement.

>
> Default is not related to whether whether a null is acceptable or
> desirable or not (at the client or the server).
>
> A foreign key value specifies a relationship. The only mechanism
> for supporting "no relationed row exists" is a NULL. Hence the
> operation of LookupCombo - which is designed for the maintenance
> of foreign keys.

You're talking apples and oranges here. Conceptually, a empty
result-set is a NULL, but we are not talking about the result-set
here... We are talking about the physical value of how a NULL result-
set is stored in a integer foreign-key field.. and NULL is not a
valid integer, and to eliminate this possibility I have added a
constraint within IBO via the DefaultValues entry which is sometimes
used and sometimes not.

Geoff, I really appreciate your views, but we have had this type
of discussion before (Scroll Events) where I come from the developer
and usability side and you come at it from the IBO/server side...
All I know is that the INSERT values that are sent to the server via
IBO are inconsistent depending on the actions of the user, and this
is wrong.

> If you want different behaviour write it! And you are right, using
> BeforePost events is inefficient and error prone. You should be
> deriving your own components.

Are you saying that a 1,000 IBO developers must write their own
individual code (BeforePosts or triggers or derived classes) to do
something that could (and should) be done easily by the component
library?
(The LookupCombo component only has to scan the DefaultValues
list, pick-out the relevant value, and stick it in the buffer if the
user hits a DEL).

>
> And if you truly want your database to be reliable and consistent
> then you must be prepared to write triggers to enforce your rules.
> Its a PITA I know, but without this your entire application is
> resting on the assumption that no-one will ever access your data
> from outside your client application - and this is not usually a
> safe assumption.

I like your thought here, and I will take it in to account in the
future.

Eric.