Vincoli di controllo (CHECK constraints)

È stato spesso detto in questa guida che quando un'espressione di confronto riporta NULL, ha lo stesso effetto di false: la condizione non è cioè soddisfatta. A partire da Firebird 2, questo noè più vero per i vincoli di controllo, cioè i «CHECK constraint». Per conformità allo standard SQL, un vincolo di CHECK adesso è soddisfatto se la condizione vale NULL. Solo un vero e proprio false provoca un rigetto del dato immesso.

In pratica, questo signica che controlli come

check ( value > 10000 )

check ( upper( value ) in ( 'A', 'B', 'X' ) )

check ( value between 30 and 36 )

check ( ColA <> ColB )

check ( Comune not like 'Mila%' )

...non accettano un dato NULL in Firebird 1.5, ma lo fanno passare in Firebird 2. Gli script di creazione per database già esistenti hanno bisogno di essere attentamente riesaminati prima di riusarli in Firebird 2. Bisogna riadattarli nel caso in cui un dominio o una colonna non ha un vincolo NOT NULL, e il relativo controllo di CHECK può diventare NULL, il che succede spesso ma non esclusivamente quando il dato in ingresso è NULL. Il vincolo di controllo può essere ad esempio esteso così:

check ( value > 10000 and value is not null )

check ( Comune not like 'Mila%' and Comune is not null )

Tuttavia, è più semplice e più chiaro aggiungere un NOT NULL alla definizione del dominio o della colonna:

create domain DSTIPENDIO int not null check ( value > 10000 )

create table Luoghi
(
  Comune varchar(24) not null check ( Comune not like 'Mila%' ),
  ...
)

Se gli script o i database devono funzionare in modo consistente in tutti i server vecchi e nuovi, bisogna fare in modo da evitare che qualsiasi vincolo di CHECK possa trasformarsi in NULL. Si può aggiungere «or ... is null» per permettere un NULL in input nelle versioni più vecchie. Si può aggiungere un vincolo di NOT NULL oppure restrizioni come «and ... is not null» per impedirne l'accettazione esplicitamente nelle versioni di Firebird più recenti.