At 09:05 PM 20/03/2003 +0100, you wrote:

>hello Helen,
>
> > Ok, now, what you achieve here is to force
> > the current value of :DESCRIPTION into the
> > VALUES() list of the insert, thereby making
> > it "a value" rather than a "non-value". So -
> > because you forced the value-list to take
> > this "value" of <whatever> (in this case, an
> > empty string), BLANKISNULL is not applied.
>
>There is something that is not clear. BLANKISNULL is not applied
>because I have set CheckRequired := False, isn't it?

No. BLANKISNULL is not applied because your XxxxxSQL is forcing the
parameter to be "something" (i.e. it is saying "I don't care what the value
is, please use it.)

> > 1. Remove the XxxxxxSQL properties and let
> > IBO do what you have set it up to do. Since
> > there seems to be nothing special about these
> > XxxxxxSQL statements, that will be your best
> > remedy.
>
>But if I remove the xxxxSQL properties, the TIB_Query becomes
>read-only, isn't it?

No. Set the RequestLive property to true and IBO will construct the DML
statement automatically, and obey all rules which you have set for it
(including BLANKISNULL).

>And if I remove them, how are the insert, edit
>and delete statements managed?

Automatically.

>Do I have to manage them in code?

No.
Use XxxxxSQL properties when you have a dataset which would not otherwise
be updatable (e.g. a joined or unioned set, or a set that comes from a
Select procedure). In general, XxxxxSQL would execute a stored
procedure. XxxxxSQL will accept parameters directly from the dataset, if
the SP parameters are of the same type and name as the corresponding
dataset fields.

The SP can have other parameters as well, not matched in the dataset. In
this case, you will need some code, e.g. on your Post buttonclick, to pass
values to these unhandled parameters.

> > But I'm still dense as to why you want to
> > defer validation until a Post fails. It
> > would be better in all ways to make the
> > exception occur during CheckRequired and
> > have the user correct the problem *before*
> > the Post attempt (a client-to-server
> > operation) occurs and fails.
>
>I prefer to have an EIB_ISC_Error that I can trap in the OnError
>handler of the TIB_Query executing my own error dialog instead of the
>standard IBO error dialog that is executed during CheckRequired test
>because for me it is easier to localize. It's very difficult to
>localize the standard IBO error dialog.

<sigh>

>And I usually prefer to always manage by myself all errors.

An EIB_DatasetError is just another Exception class inherited from
EIB_Error, as is EIB_ISCError...

Helen