hello Helen,

> Are you watching an IB_MonitorDialog, to see
> what values are going through in your SQL?

yes, I've done it. Even if I leave the DESCRIPTION field empty, an
empty string is going through my SQL instead of a NULL.

> Have you touched the BLANKISNULL attribute at all?

yes and no <g> With BLANKISNULL checked or not, the result is always
the same as above.

> Is there any possibility that you have DEFAULT
> assigned for these columns (these work only on
> inserts), or that you are handling NULL via
> triggers?

No, the DESCRIPTION field doesn't have any DEFAULT value and I'm not
handling it in any trigger. Here is its definition, along with the
table definition and the only trigger for that table:

CREATE DOMAIN CH_EVENT_DESC
AS VARCHAR(50)
NOT NULL
COLLATE BETA_ISO8859_1_NOCASE;

[snip]

CREATE TABLE Events(
ID_Event INT_ID,
Description CH_EVENT_DESC,
Expiry_Date DATE_EXPIRY_DATE,
Alert_Days_Before INT_EVENT_ALERT_DAYS,
Alert_Days_After INT_EVENT_ALERT_DAYS,
Event_Enabled LOGICAL);

[snip]

CREATE TRIGGER BI_EVENTS FOR Events
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW.ID_Event IS NULL) THEN
NEW.ID_Event = GEN_ID(GEN_ID_Event, 1);
END ^

[snip]

> Yes, if NULL is not being handled by a trigger
> or a DEFAULT, you should get an EIB_ISCError
> if Post fails. Post *should* fail if NULL is
> passed to a non-nullable column. The EIB_ISCError
> is transformed into a structure which you can
> read in the OnError event.

yes, this should be the case, but the OnError handler is never fired.

Cheers
Salvatore