Altri problemi

NULL in colonne NOT NULL
NULL illegali riportati come 0, '', ecc.
Chiavi primarie con valori a NULL
SUBSTRING descritta come non annullabile
Gbak -n recupera i NOT NULL
IN, =ANY e =SOME con subselect indicizzate
ALL con subselect indicizzate
SELECT DISTINCT con l'ordinamento sbagliato di NULLS FIRST|LAST
UDF che riportano valori invece di riportare NULL
UDF che riportano NULL quando invece dovrebbero riportare un valore
SINGULAR inconsistente con risultati a NULL

`NULL` in colonne NOT NULL

I NULL possono esistere nelle colonne NOT NULL nelle seguenti situazioni:

Se si aggiunge una colonna NOT NULL ad una tabella già piena, i campi della colonna aggiunta saranno tutti NULL.
Se si rende una colonna esistente NOT NULL, ogni NULL già presente nella colonna rimane in quello stato.

Firebird permette a quei NULL di restare, e ne permette il backup, ma si rifiuta di recuperare la copia con gbak. Vedere Aggiungere una colonna NOT NULL and Rendere una colonna esistente NOT NULL.

`NULL` illegali riportati come `0`, `''`, ecc.

Se una colonna NOT NULL contiene NULL (vedere il problema precedente), il server lo descrive come non annullabile al programma client. Poichè molti programmi si fidano ciecamente del server, interpretano quei NULL come se fossero 0 (o equivalente) e come tale lo presentano all'utente. Vedere Valorizzazione errata di NULL come se fosse zero.

Chiavi primarie con valori a `NULL`

Il problema seguente è comparso in Firebird 1.5: avendo una tabella con dati, ed aggiungendo una colonna NOT NULL (che automaticamente crea dei NULL nelle righe esistenti– vedi sopra), è possibile rendere quella colonna la chiave primaria anche se ha già dei valori NULL. In 1.0 questo non sarebbe potuto funzionare a causa delle regole più restrittive per gli indici UNIQUE. Risolto nella versione 2.0.

SUBSTRING descritta come non annullabile

Il sistema descrive le colonne risultato di una SUBSTRING come non annullabili nei seguenti due casi:

Se il primo argomento è una costante stringa, come in «SUBSTRING( 'Paperino' FROM 5 FOR 2 )».
Se il primo argomento è una colonna NOT NULL

Questo è sbagliato perchè perfino di una stringa nota, la sottostringa può essere NULL quando il primo degli altri argomenti è NULL. Nella versione 1.* qusto non era un problema: gli argomenti del FROM e del FOR dovevano essere per forza costanti, pertanto non avrebbero mai potuto essere NULL. Ma a partire da Firebird 2, è permessa ogni espressione idonea a rappresentare il tipo di dato richiesto. E sebbene il sistema correttamente riporti NULL se un argomento è NULL, descrive la colonna risultato come non annullabile, cosicchè molti programmi mostrano il risultato come stringa vuota.

Questo problema sembra risolto a partire dalla versione 2.1.

Gbak -n recupera i NOT NULL

Gbak -n[o_validity] recuperava i vincoli NOT NULL nelle prime versioni di Firebird. Risolto nella versione 1.5.1.

IN, =ANY e =SOME con subselect indicizzate

Sia A be l'espressione sinistra e S il risultato di una subselect. Nelle versioni precedenti la 2.0, «IN», «=ANY» e «=SOME» riportavano false invece di NULL se un indice era attivo nella colonna della subselect e:

o A è NULL e S non contiene NULL;
o A non è NULL, A non esiste in S, e S contiene almeno un NULL.

Vedere gli avvertimenti nelle sezioni IN e ANY. Alternativa: usare invece «<> ALL» . Risolta nella versione 2.0.

ALL con subselect indicizzate

Con qualsiasi operatore, eccetto «<>», ALL può dare risultati sbagliati se un indice è attivo sulla colonna della subselect. Questo può capitare con o senza NULL. Vedere Problemi di ALL. Risolto nella versione 2.0.

SELECT DISTINCT con l'ordinamento sbagliato di NULLS FIRST|LAST

Firebird 2.0 ha il seguente problema (difficile da spiegare senza esempi): se una SELECT DISTINCT è ordinata con [ASC] NULLS LAST o DESC NULLS FIRST, ed i campi di ordinamento (nella ORDER BY) formano solo l'inizio ma non sono tutti i campi della lista nella SELECT, ogni campo nella clausola ORDER BY che è seguito nella SELECT da un campo con un ordinamento differente (o nessun ordinamento) si ritrova i NULL posizionati in modo default, ignorando la direttiva NULLS XXX. Risolto nella versione 2.0.1 e 2.1.

UDF che riportano valori invece di riportare `NULL`

Questo dev'essere certamente considerato un problema. Se un'angolo è sconosciuto, non si può affermare che il suo coseno è 1! Sebbene tutta la storia di queste funzioni sia ben nota ed è comprensibile il perchè si comportino così (vedere Funzioni definite dall'utente (UDF)), è comunque sbagliato. Sono riportati valori errati e questo non dovrebbe accadere. La maggior parte delle funzioni matematiche nella ib_udf, oltre a qualche altra, hanno questo problema.

UDF che riportano `NULL` quando invece dovrebbero riportare un valore

Questo è un problema complementare al precedente. LPAD ad esempio riporta NULL se si vuol riempire una stringa vuota con, ad esempio, 10 punti. Questa ed altre funzioni sono state corrette nella versione 2.0, con l'avvertenza che bisogna esplicitamente dichiararle con la parola chiave NULL, altrimenti si comporteranno nel modo sbagliato di una volta. LTRIM e RTRIM trasformano stringhe vuote in NULL in Firebird 1.0.n. Questo è stato risolto nella versione 1.5 al prezzo di riportare stringa vuota (cioè '') se l'argomento è una stringa NULL, e completamente risolto solo nella versione 2.0 (se dichiarata con la parola chiave NULL).

SINGULAR inconsistente con risultati a `NULL`

NOT SINGULAR talvolta riporta NULL quando SINGULAR riporta true o false. Risolto nella versione 2.0.

SINGULAR può erroneamente riportare NULL, in un modo riproducibile ma inconsistente. Risolto nella versione 2.1.

Vedere la sezione su SINGULAR.

Altri problemi

NULL in colonne NOT NULL

NULL illegali riportati come 0, '', ecc.

Chiavi primarie con valori a NULL