Commented by: @hvlad

> f1=1, f2=2, f3=null
> f1=1, f2=2, f3=null
>
> if I make a query
>
> select * from table1 t where
> f1=1
> and f2=2
> and f3 is null
>
> the result contains only one of the records if the plan is using the "UNQ1_TABLE1" index
> the result contains both records if PLAN (T NATURAL) is used.

Looks like corrupted index. Run gfix -v -fu and show result here, please.

> After backup and restore under FB2.5 the problem persists.

I you mean that at restore FB not allows to create unique index on duplicated data then it is expected behavior. Same as below:

> If I drop the index and try to create it again I receive the error: "Invalid insert or update value(s): object columns are constrained - no 2 table rows can have duplicate column values.
> attempt to store duplicate value (visible to active transactions) in unique index "UNQ_STOCK"."

> One of the null values is not exactly null

I don't understand this. Please explain.

Commented by: Sean Leyne (seanleyne)

Your example does not show a commit between the DDL (table definition, CREATE/ALTER TABLE) statements and the DML (Data manipulation) statements (INSERT...). This is BAD, the 2 classes of statements should NOT be mixed.

Is the commit really missing or is it a typo?