I Database creati o recuperati da un backup sotto Firebird 2 hanno una struttura su disco (ODS) di livello 11 o superiore.

(v.2.1) Questi nuovi «database triggers» sono moduli PSQL definiti dall'utente che possono essere utilizzati per l'esecuzione durante gli eventi a livello di connessione o di transazione. Vedere Trigger a livello di database.

(v.2.1) Il protocollo remoto è stato ampiamente migliorato per operare meglio nelle reti lente dal momento stesso in cui i driver vengono aggiornati per utilizzare le modifiche. I controlli hanno mostrato una diminuzione di round trip API del 50% circa, con una diminuzione del 40% dei round trip TCP. Vedere Remote Interface Improvement.

Il supporto per le tabelle derivate in DSQL (cioè subqueries nella clausola FROM) come definite nello standard SQL200X. Una tabella derivata è un set derivato da uno statement dinamico di SELECT. Le tabelle derivate possono essere innestate, se necessario, per costruire query ancora più complesse e possono far parte di JOIN come se fossero normali tabelle o viste.

Altri dettagli in Tabelle derivate nel capitolo relativo al DML.

Sono supportati più cursori nominativi (cioè espliciti) in PSQL e nello statement DSQL EXECUTE BLOCK. Altre informazioni nel capitolo sul PSQL Cursori esplicitati.

Sono state fatte due modifiche sostanziali al protocollo in Windows.

Fin da prima di Firebird 1.0, il motore Superserver eseguiva un sistema di background garbage collection (un processo per il recupero della memoria non più utilizzata), gestendo informazioni su ogni nuova versione dei record prodotta da una frase UPDATE o DELETE. Nel momento stesso in cui la vecchia versione non risultava più «interessante», cioè diventava più vecchia della più vecchia transazione snapshot (Oldest Snapshot, si vede nell'output del comando gstat -header) il motore segnala al sistema di recupero di rimuoverla o, in altre parole, di liberare la memoria che prima era occupata dalla versione del record.

Il motore Classic e le versioni di Interbase precedenti la 6.0 avevano un altro sistema di Garbage Collection, noto come garbage collection cooperativo. Questo sistema, cioè il GC cooperativo, ha la necessità di rileggere le pagine contenenti le versioni dei record non più interessanti attraverso un SELECT COUNT(*) FROM aTable oppure altre query di scansione di tabella da parte di un utente. Il GC in background non ha questa necessità; inoltre risolve il problema di recuperare la memoria per quelle pagine che vengono lette raramente.

Uno sweep, naturalmente, troverebbe queste versioni dei record non utilizzate e le cancellerebbe, ma questo non accade necessariamente a breve termine. Un ulteriore beneficio è la riduzione di I/O, a causa dell'alta probabilità che le pagine richieste risiedano già nella memoria cache.

Tra il momento in cui il motore notifica al garbage collector l'esistenza di pagine che contengono versioni non più usate ed il momento che il garbage collector riesca a leggere quella pagina, una nuova transazione potrebbe aggiornare uno dei record contenuti. Il garbage collector non può pulire il record se questo numero di transazione successivo è maggiore dell'Oldest Snapshot oppure è ancora attivo. Il motore poi notifica ancora al garbage collector lo stesso numero di pagina, sovrascrivendo la precedente notifica e pertanto la pulizia dovrà essere fatta in un tempo successivo.

In Firebird 2.0 Superserver, sono possibili contemporaneamente sia il GC cooperativo che quello in background. Per gestirli, è stato introdotto un nuovo parametro di configurazione GCPolicy che può essere impostato a:

È stato completata la codifica delle API di servizio per l'architettura Classic. Sono pertanto disponibili tutte le funzioni API sia su Linux che su Windows per i server Classic, senza limitazione alcuna. Sono state eliminate pure tutte le problematiche note riguardo agli errori di gsec riportate nelle precedenti versioni di Firebird.

Tutte le versioni di Firebird hanno due modi di attesa per le transazioni: NO WAIT e WAIT. Il modo NO WAIT significa che i conflitti di blocco e di abbraccio mortale (deadlock) sono riportati immediatamente, mentre con WAIT la transazione attende bloccata finché le transazioni concorrenti finiscono venendo confermate (commit) o rinunciate (rolled back).

Questa nuova caratteristica estende la modalità WAIT permettendo di impostare un tempo finito di attesa delle transazioni concorrenti. Alla scadenza del tempo viene riportato un errore (isc_lock_timeout).

Gli intervalli di attesa sono specificati a livello di transazione, usando la nuova costante TPB isc_tpb_lock_timeout nell'API oppure, in DSQL, la clausola LOCK TIMEOUT <value> della frase SET TRANSACTION.

Un rifacimento è stato fatto per risolvere i problemi relativi alle viste che sono implicitamente aggiornabili, ma mantengono ancora dei trigger di UPDATE. Questa è un'importante modifica che influenza i sistemi con procedure scritte per avvantaggiarsi di una (dis)funzione non documentata delle precedenti versioni.

Per i dettagli, vedere nelle note nel capitolo riguardo alla compatibilità nel documento separato delle Note di Installazione.

Sono stati implementate le modalità Single-user (utente singolo) e full shutdown (spegnimento completo) usando il nuovo parametro [state] per i comandi gfix -shut e gfix -online.

Sintassi attuale

    gfix <command> [<state>] [<options>]
    <command>> ::= {-shut | -online}
    <state> ::= {normal | multi | single | full}
    <options> ::= {-force <timeout> | -tran | -attach}
    

Per ulteriori dettagli, vedere la sezione su Gfix in New Shutdown Modes, nel capitolo dei programmi di utilità.

Per una lista dei simboli di stato di spegnimento ed esempi di di uso, vedere Shutdown State in the API.

Il controllo per il sovradimensionamento nella concatenazione di stringhe è stato spostato dalla fase di compilazione alla fase di run-time.

A partire da Firebird 1.0, le operazioni di concatenazione vengono controllate per evitare che la stringa risultante possa superare il limite di circa 32,000 bytes, cioè un sovradimensionamento (overflow). Questo controllo veniva effettuato durante la fase di preparazione dello statement, usando le dimensioni dichiarate degli operandi ed avrebbe dato errore per una espressione dl tipo:

  CAST('qwe' AS VARCHAR(30000)) || CAST('rty' AS VARCHAR(30000))
    

A partire da Firebird 2.0, questa espressione lancia solo un'avvertenza (warning) durante la fase di preparazione ed il controllo di sovradimensionamento viene ripetuto all'esecuzione, usando la dimensione degli operandi reali. Il risultato permette all'esempio di essere eseguito senza errori. L'eccezione isc_concat_overflow viene ora pertanto lanciata solo per i sovradimensionamenti reali, riportando pertanto il funzionamento della loro rilevazione simile a quella delle operazioni aritmetiche.

(N.d.T. quanto segue è veramente tecnico anche in lingua originale. Di solito rinuncio a tradurre tali termini quando sono così per addetti ai lavori.)

Firebird 2.0 supporta le piattaforme a 64-bit.

È stato introdotto il conteggio dei record a 40-bit (64-bit internamente) per superare il limite di circa 30GB per tabella imposto dal precedente limite a 32-bit.

Le versioni per Posix SS ora gestiscono SIGTERM e SIGINT per chiudere tutte le connessioni in modo corretto e non brusco. (A. Peshkov)

Il tracciamento degli invarianti è quel processo eseguito dal compilatore BLR e dall'ottimizzatore per decidere se una certa espressione (come potrebbe essere una subquery interna) è "invariante", cioè indipendente dal contesto principale. Viene usato per eseguire una unica valutazione di tali espressioni e di riutilizzare i risultati senza ricalcolarli.

La gestione del tracciamento degli invarianti in PSQL e la logica di duplicazione delle richieste sono state rifatte per risolvere un certo numero di problemi con le procedure recursive, ad esempio SF bug #627057.

Se alcune invarianti sfuggono alla determinazione, c'è una perdita di prestazioni. Se alcune variabili sono trattate come invarianti, si ottengono risultati errati.

Esempio

  select * from rdb$relations
    where rdb$relation_id <
      ( select rdb$relation_id from rdb$database )
    

Questa query esegue solo una lettura da rdb$database invece di valutare la subquery per ogni riga di rdb$relations.

Firebird 2.0 aggiunge un opzionale clausola RETAIN allo statement DSQL ROLLBACK per renderlo simmetrico al COMMIT [RETAIN].

Vedere ROLLBACK RETAIN nel capitolo sul DML.

La ricerca del direttorio radice è stata modificata in modo tale che i processi server su Windows non cercano più di leggere la Registry.

Nelle procedure dell'ottimizzatore sono stati migliorati i calcoli per la scelta degli indici.

Dalla versione 2.1.2
Alcuni parametri di DPB sono stati resi inaccessibili all'utente generico, in modo da chiudere alcuni buchetti pericolosi. In alcuni casi questi riguardano impostazioni che potrebbero modificare le impostazioni nell'header del database e potenzialmente provocare disastri se non effettuate sotto il controllo dell'amministratore; in altri, iniziano operazioni che sono riservate al solo SYSDBA. Esse sono:

Il parametro isc_dpb_set_page_buffers può essere ancora usato da utenti generici in architetture Classic per impostare temporaneamente la dimensione del buffer solo per quella sessione di quel particolare utente. Quando è usato dal SYSDBA, in entrambe le architetture (Superserver o Classic) modifica il numero dei buffers direttamente nell'header del database, facendo pertanto una modifica permanente alla dimensione di default del buffer.

Il file da includere in linguaggio C, ibase.h è stato ripulito, in modo tale che non siano più incluse definizioni private nelle parti di interfaccia pubbliche.

Questa nuova caratteristica estende la gestione delle transazioni WAIT dando la possibilità di definire un tempo finito per la transazione corrente. Alla scadenza, viene lanciato un errore (isc_lock_timeout).

Gli intervalli possono essere specificati a livello di transazione, usando nell'API la nuova costante di TPB, isc_tpb_lock_timeout.

Per ritrovare anche gli alias delle relazioni, se necessario, è stata estesa la chiamata isc_dsql_sql_info().

isc_blob_lookup_desc() è in grado ora di descrivere i blob che sono output di stored procedure.

La definizione macro FB_API_VER è stata aggiunta in ibase.h per recuperare la versione attuale delle API. Il numero corrisponde alla versione Firebird appropriata.

Il valore attuale di FB_API_VER è 20 (due cifre equivalenti a 2.0). Questa macro può essere usata dalle applicazioni per verificare la versione di ibase.h con cui vengono compilate.

Alla struttura della chiamata a funzione isc_database_info() sono state aggiunte le seguenti opzioni:

Alla struttura della chiamata a funzione isc_transaction_info() sono stati aggiunti le seguenti opzioni:

isc_info_tra_isolation,
  1, isc_info_tra_consistency | isc_info_tra_concurrency |
  2, isc_info_tra_read_committed,
     isc_info_tra_no_rec_version | isc_info_tra_rec_version
          

isc_info_tra_access, 1, isc_info_tra_readonly | isc_info_tra_readwrite
        

Sono stati eseguiti i seguenti miglioramenti alle API di servizio:

Per estrarre il testo di un messaggio d'errore Firebird dal vettore di stato in un buffer utente, la nuova funzione  fb_interpret()  sostituisce la precedente isc_interprete().

L'accesso API alla sconnessione del database è effettuata attraverso i flag aggiunti al parametro isc_dpb_shutdown nell'argomento DBP passato alla isc_attach_database(). I simboli per i flag di stato adesso sono:

#define isc_dpb_shut_cache               0x1
#define isc_dpb_shut_attachment          0x2
#define isc_dpb_shut_transaction         0x4
#define isc_dpb_shut_force               0x8
#define isc_dpb_shut_mode_mask          0x70

#define isc_dpb_shut_default             0x0
#define isc_dpb_shut_normal             0x10
#define isc_dpb_shut_multi              0x20
#define isc_dpb_shut_single             0x30
#define isc_dpb_shut_full               0x40
        

Esempio di uso in C/C++

char dpb_buffer[256], *dpb, *p;
ISC_STATUS status_vector[ISC_STATUS_LENGTH];
isc_db_handle handle = NULL;

dpb = dpb_buffer;

*dpb++ = isc_dpb_version1;

const char* user_name = «SYSDBA»;
const int user_name_length = strlen(user_name);
*dpb++ = isc_dpb_user_name;
*dpb++ = user_name_length;
memcpy(dpb, user_name, user_name_length);
dpb += user_name_length;

const char* user_password = «masterkey»;
const int user_password_length = strlen(user_password);
*dpb++ = isc_dpb_password;
*dpb++ = user_password_length;
memcpy(dpb, user_password, user_password_length);
dpb += user_password_length;

// Per forzare un completo scollegamento del database
*dpb++ = isc_dpb_shutdown;
*dpb++ = 1;   
*dpb++ = isc_dpb_shut_force | isc_dpb_shut_full;

const int dpb_length = dpb - dpb_buffer;

isc_attach_database(status_vector,
                    0, «employee.db»,
                    &handle,
                    dpb_length, dpb_buffer);

if (status_vector[0] == 1 && status_vector[1])
{
  isc_print_status(status_vector);
}
else
{
  isc_detach_database(status_vector, &handle);
}
        

Firebird 2.0 crea i database con un ODS con versione 11.

La dimensione massima per i messaggi di eccezione è aumentata da 78 a 1021 bytes.

Il campo RDB$DESCRIPTION è stato aggiunto alla tabella RDB$GENERATORS, così da poter aggiungere testi descrittivi ai generatori creati.

I campi RDB$DESCRIPTION e RDB$SYSTEM_FLAG sono stati aggiunti alla tabella RDB$ROLES per permettere rispettivamente un testo descrittivo e determinare i ruoli definiti dall'utente.

Per distinguere i database Firebird da quelli Interbase, è stato introdotto il concetto di tipo di ODS.

Il parser del DSQL cerca ora di descrivere anche la linea e la colonna in cui determina una frase incompleta.

Per memorizzare la selettività di ciascun segmento di un indice multi-chiave, è stata aggiunta la colonna RDB$STATISTICS alla tabella di sistema RDB$INDEX_SEGMENTS.

Alcuni test su Linux mostrarono che impostando o meno O_SYNC scrivendo file non cambiavano per nulla le prestazioni! Bene, si poteva pensare di avere un sistema operativo veloce. Invece no: è un problema documentato del kernel di Linux!

Stando al manuale di Linux, «Su Linux, questo comando (cioè fcntl(fd, F_SETFL, flags)) può solo cambiare i flag O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME, e O_NONBLOCK». Sebbene non sia documentato in nessun posto a me noto, qualsiasi tentativo di impostare ogni altro flag oltre a quelli citati nel manuale (come appunto O_SYNC, ad esempio) oltre a non funzionare, fcntl() non riporta nemmeno nessun messaggio o stato di errore.

Per le versioni di Firebird e Interbase fino a questo punto, significa che le Forced Writes su Linux non hanno mai funzionato. Su Windows invece funzionano (e hanno funzionato) correttamente. Sembra inoltre che tal problema non abbia influenzato altri sistemi operativi, sebbene non si possa garantirlo. Per essere sicuri bisogna controllare se l'implementazione di fcntl() nel proprio sistema operativo è in grado di impostare il flag O_SYNC.

La tecnica usata adesso, introdotta nella versione Beta 2 di Firebird 2.1, è quella di riaprire il file. Questo dovrebbe garantire la corretta operatività in ogni sistema operativo, premesso che la chiamata di sistema open() funzioni correttamente sotto questo aspetto. Apparentemente finora nessuno ha mostrato questo tipo di problemi.

Il team di sviluppo di Firebird non si riesce a spiegare perché un tale buco possa rimanere irrisolto per due anni dopo essere stato immesso nel Linux kernel's bug-tracker. Apparentemente, in Linux un problema documentato diventa una caratteristica...

Questo è un suggerimento per una soluzione rapida al problema per le versioni precedenti di Firebird: usare l'opzione «sync» su ogni partizione montata con un database Firebird installato. Un esempio di una linea in /etc/fstab:

Spostare un database su una periferica fisica è semplice come recuperare una copia direttamente su una partizione non formattata nel sistema di dischi locale. Ad esempio,

 gbak -c miacopia.fbk /dev/sda7
      

recupera la copia di nome miacopia.fbk nel terzo disco logico della partizione estesa del primo disco rigido SCSI o SATA (disk0).

Per evitare che il file differenziale del programma di utilità fisico nbackup venga scritto nel direttorio /dev/, bisogna attribuirgli un nome file completo in modo esplicito. Questo si ottiene usando ad esempio ISQL, attraverso il seguente comando:

# isql /dev/sda7
SQL> alter database add difference file '/tmp/dev_sda7';
      

# nbackup -s -l /dev/sda7
77173
        

Sebbene non siano noti problemi specifici ad oggi sull'uso delle periferiche fisiche per i database, bisogna tenere presente che

Per passare l'identificatore del set di caratteri della connessione oppure il set di caratteri di un BLOB, quando il set di caratteri della connessione è NONE, si usa l'elemento XSQLVAR::sqlscale dei BLOB di tipo testo.

Caratteristica richiesta CORE-1069

Nel caso in cui più di un indice deve essere letto a causa di congiunzioni AND, è stata operata una ottimizzazione.

Caratteristica richiesta CORE-1070

Nel caso in cui i valori sono per lo più consecutivi, sono state ottimizzate le operazioni bitmap (set, test e clear).

Caratteristiche richieste CORE-958 e CORE-937

Caratteristica richiesta CORE-969

Sono sconsigliate le dimensioni di pagina da 1K e da 2K perché sono inefficienti.

Caratteristica richiesta CORE-1229

Fino a Firebird 2.1, non essendoci regole particolari nell'allocare lo spazio per le pagine dei file di database, a causa delle dipendenze delle pagine che gestisce autonomamente, per servire la strategia di «careful write», ha sempre scritto le nuove pagine appena allocate in ordine qualsiasi.

Per i database con ODS 11.1 e successive, i server Firebird a partire dalla versione 2.1 usano un algoritmo per allocare lo spazio su disco, per risolvere due problemi riconosciuti associati al sistema precedente:

Caratteristica richiesta CORE-1381 e CORE-1480

Per la memoria tampone delle pagine, Firebird usa e gestisce un suo proprio sistema di cache in memoria. Il sistema operativo, a sua volta, potrebbe avere parte degli stessi dati gestiti nella memoria tampone propria del filesystem. Configurando Firebird ad usare una memoria cache relativamente grande rispetto alla memoria disponibile e ad usare le Forced Writes, questa duplicazione della memoria cache può consumare così tante risorse disponibili da non dare nessun beneficio.

Inoltre, se il sistema operativo cerca di gestire un file grandissimo, può spostare la cache delle pagine di Firebird addirittura in swap, provocando un'intensa (e inutile) paginazione su disco. In pratica, se la dimensione della cache delle pagine di Firebird Superserver è oltre l'80% della RAM disponibile, la gestione delle risorse potrebbe risultare insostenibile.

Adesso Superserver, sia su Windows che POSIX, ha un nuovo parametro di configurazione, MaxFileSystemCache, per (dis)abilitare la cache del filesystem. Può permettere di avere più memoria libera per altre operazioni (es. l'ordinamento) e, dove ci sono molti database, può ridurre le richieste di risorse all'host.

Per dettagli sul parametro MaxFileSystemCache, vedere MaxFileSystemCache.

Caratteristica richiesta CORE-1071

Il processo di raccolta in background leggeva tutte le versioni precedenti dei record su una pagina, comprese quelle create da transazioni attive. Poiché queste ultime non vanno considrate per la garbage collection, era una perdita di tempo leggerle.

Caratteristica richiesta CORE- 961

Il motore ora rilascia i file esterni non appena sono rilasciate da qualsiasi richiesta degli utenti.

Richiesta CORE-976

Dettagli assenti.

Richiesta CORE-1169

La conversione tra il blob temporanea ed il tipo di blob destinazione avviene solo alla materializzazione e non prima.

Richiesta CORE-779

È stato introdotto un flag di tipo per le stored procedure, aggiungendo la colonna RDB$PROCEDURE_TYPE alla tabella RDB$PROCEDURES. I possibili valori sono:

Richiesta CORE-1558

Il server, normalmente, dopo un problema grave (bugcheck) cerca di proseguire le operazioni. Il parametro di configurazione BugcheckAbort fa in modo invece di chiamare immediatamente la funzione abort() e creare un file di core dump. Poiché il bugcheck è il risultato di un problema non riconosciuto dal server, continuare le operazioni con un problema non risolto non dovrebbe essere comunque possibile, id il file di core dump può dare informazioni utili per il debug.

Nelle distribuzioni più recenti di Linux, quando un'applicazione abortisce per default non viene più fatto il core dump core. Gli utenti hanno spesso problemi nell'ottenerlo. Le regole diverse tra Classic e Superserver, oltre all'inconsistenza tra gli strumenti di gestione del sistema operativo tra ditribuzione e distribuzione, rendono pressoché impossibile aiutare l'utente generico con una qualsiasi «regola generale».

Pertanto è stato aggiunto, al Classic e al Superserver su Linux, codice per neutralizzare questi problemi ed automatizzare la generazione di un file di core dump all'abort() causato da BUGCHECK. Il server Firebird esegue il necessario 'cwd' (change working directory) ad una locazione scrivibile (/tmp) e imposta la dimensione limite del file di core in modo tale che il limite 'soft' eguagli il limite 'hard'.

(v.2.1) Un trigger di database è un modulo scritto in PSQL che viene eseguito in associazione ad un evento di connessione o di transazione. Gli eventi e relativo ordine sono come segue.-

Sintassi

<database-trigger> ::=
  {CREATE | RECREATE | CREATE OR ALTER}
    TRIGGER <name>
    [ACTIVE | INACTIVE]
    ON <event>
    [POSITION <n>]
  AS
    BEGIN
      ...
    END

<event> ::=
  CONNECT
    | DISCONNECT
    | TRANSACTION START
    | TRANSACTION COMMIT
    | TRANSACTION ROLLBACK
      

Regole e limitazioni

  gbak -nodbtriggers
  isql -nodbtriggers
  nbackup -T
        

(v.2.1) Le tabelle temporanee globali (GTT) sono tabelle memorizzate permanentemente nel metadata del sistema, ma con dati temporanei. I dati provenienti da differenti connessioni (o transazioni in funzione della definizione) sono isolati gli uni dagli altri, ma il metadata della GTT è condiviso fra tutte le connessioni e transazioni.

Pertanto ci sono due tipi di GTT:

CREATE GLOBAL TEMPORARY TABLE
  ...
  [ON COMMIT <DELETE | PRESERVE> ROWS]
	

In Firebird 2.1 sono stati fatti un paio di miglioramenti alle definizioni delle viste.-

CREATE VIEW V_TEST AS
  SELECT ID,
         COL1 AS CODICE,
         COL2 AS NOME
  FROM TABELLA;
        

Richiesta CORE-711

(v.2.1) È disponibile una sintassi alternativa per il CREATE TRIGGER che è in accordo a SQL2003.

Schemi sintattici

Forma esistente

create trigger t1
  FOR atable
  [active] before insert or update
as
  begin
    ...
  end
      

Forma SQL2003

create trigger t2 
  [active] before insert or update 
  ON atable
as 
  begin
    ...
  end
      

Notare la posizione differente della clausola identificante la tabella e le differenti parole chiave che precedono il nome della tabella (esistente FOR; SQL2003: ON).

Entrambe le sintassi sono valide e disponibili per tutti i CREATE TRIGGER, RECREATE TRIGGER e CREATE OR ALTER TRIGGER.

Richiesta CORE-1386

(v.2.1) Per definire un campo calcolato in una CREATE TABLE o ALTER TABLE, è stata resa disponibile la sintassi alternativa GENERATED ALWAYS AS conforme a SQL.

Sintassi

<nome colonna> [<tipo>] GENERATED ALWAYS AS ( <espressione> )
      

è completamente equivalente alla forma compatibile con le versioni precedenti:

<nome colonna> [<tipo>] COMPUTED [BY] ( <espressione> )
      

Esempio

CREATE TABLE T (PK INT, EXPR GENERATED ALWAYS AS (PK + 1))
      

È stata introdotta la parola chiave SEQUENCE come sinonimo di GENERATOR, in accordo con lo standard SQL-99. SEQUENCE è un termine descritto nelle specifiche SQL, mentre GENERATOR è un termine compatibile InterBase. L'uso della sintassi standard SEQUENCE è raccomandata nelle applicazioni.

Un generatore di sequenza è un meccanismo per generare valori numerici interi incrementali, uno alla volta. Un generatore di sequenza è un oggetto dello schema con nome, che in dialetto 3 è BIGINT, mentre in dialetto 1 è INTEGER.

Sintassi

    CREATE { SEQUENCE | GENERATOR } <nome>
    DROP { SEQUENCE | GENERATOR } <nome>
    SET GENERATOR <nome> TO <valore_partenza>
    ALTER SEQUENCE <nome> RESTART WITH <valore_partenza>
    GEN_ID (<nome>, <valore_di_incremento>)
    NEXT VALUE FOR <nome>
      

Esempi

1.

   CREATE SEQUENCE S_EMPLOYEE;
      

2.

   ALTER SEQUENCE S_EMPLOYEE RESTART WITH 0;
      

Vedere anche le note su NEXT VALUE FOR.

SYSDBA, il creatore del database ed il proprietario di un oggetto possono rilasciare i diritti su quell'oggetto ad altri utenti. Inoltre, tali diritti possono essere resi ereditabili con la clausola WITH GRANT OPTION. In tal caso il garante dà al garantito i diritti di diventare a sua volta garante per lo stesso oggetto. Il garante originale può rimuovere questa concessione al garantito con il comando REVOKE GRANT OPTION FROM user.

Tuttavia, c'è una forma secondaria che coinvolge i ruoli. Invece di specificare gli stessi diritti per diversi utenti (che presto diventa un incubo nella manutenzione), si può creare un ruolo, assegnare a questo nuovo ruolo un insieme di diritti ed infine garantire quel ruolo ad uno o più utenti. Ogni modifica ai diritti del ruolo influenzerà i diritti di tutti gli utenti a cui è stato garantito quel ruolo. Si dice anche che tutti gli utenti «appartenenti» a quel ruolo hanno i medesimi diritti.

Simmetricamente, con la clausola WITH ADMIN OPTION, il garante (di solito il creatore del ruolo) attribuisce ai garantiti la possibilità di diventare a loro volta garanti per lo stesso ruolo. Fino a FB v2, questa abilità non poteva essere rimossa senza mettere mano direttamente alle tabelle di sistema. Ora, il garante originale può rimuovere la concessione ad attribuire le garanzie del ruolo ad altri utenti con il comando REVOKE ADMIN OPTION FROM user.

I domini permettono di modificare o rimuovere i loro default. Sembra naturale pertanto che anche i campi di tabella possano essere maneggiati allo stesso modo senza manipolazione delle tabelle di sistema.

Sintassi

  ALTER TABLE t ALTER [COLUMN] c SET DEFAULT default_value;
  ALTER TABLE t ALTER [COLUMN] c DROP DEFAULT;
      

I comandi di DDL RECREATE EXCEPTION e CREATE OR ALTER EXCEPTION (richiesta SF #1167973) sono stati implementati permettendo di ricreare, oppure di creare o modificare una eccezione definita dall'utente, in funzione della sua attuale esistenza.

È stata implementato il comando ALTER EXTERNAL FUNCTION in modo da permettere la modifica dell'entry_point o del module_name della dichiarazione di una UDF, quando questa non può essere rimossa a causa di dipendenze attualmente insistenti sulla sua definizione.

Il comando COMMENT ON è stato implementato per permettere l'inserimento di descrizioni e commenti nel metadata.

Syntax Pattern

  COMMENT ON DATABASE IS {'txt'|NULL};
  COMMENT ON <basic_type> name IS {'txt'|NULL};
  COMMENT ON COLUMN tblviewname.fieldname IS {'txt'|NULL};
  COMMENT ON PARAMETER procname.parname IS {'txt'|NULL};
        

Una stringa vuota di commento, cioè '', equivale a NULL in quanto il codice interno (nel caso DYN) funziona in quel modo per i blob.

  <basic_type>:
     DOMAIN
     TABLE
     VIEW
     PROCEDURE
     TRIGGER
     EXTERNAL FUNCTION
     FILTER
     EXCEPTION
     GENERATOR
     SEQUENCE
     INDEX
     ROLE
     CHARACTER SET
     COLLATION
     SECURITY CLASS1

¹non implementato in quanto il tipo è nascosto.

Nelle specifiche di una vista si possono usare adesso anche le sintassi relative a FIRST/SKIP e ROWS e le clausole PLAN e ORDER BY.

A partire da Firebird 2.0 in poi, le viste sono trattate come espressioni di SELECT complete di tutte le caratteristiche. Di conseguenza nelle viste adesso le clausole relative a FIRST/SKIP, ROWS, UNION, ORDER BY e PLAN sono permesse e funzionano come previsto.

Sintassi

Per i dettagli della sintassi, fare riferimento a SELECT e sintassi delle espressioni nel capitolo relativo al DML.

La frase di DDL per ricreare un trigger è disponibile nella forma RECREATE TRIGGER. La sintassi è simile a quella di altre frasi di RECREATE.

Le modifiche descritte in seguito influenzano in vario modo l'utilizzo o l'esistenza di alcuni aggiramenti tecnici nelle applicazioni o nelle basi di dati delle versioni precedenti a Firebird 2.

   declare filter <name> input_type <number> output_type <number>
     entry_point <function_in_library> module_name <library_name>;
      

   declare filter <name> input_type <mnemonic> output_type <mnemonic>
     entry_point <function_in_library> module_name <library_name>;
      

select RDB$TYPE, RDB$TYPE_NAME, RDB$SYSTEM_FLAG
     from rdb$types
     where rdb$field_name = 'RDB$FIELD_SUB_TYPE';

   RDB$TYPE   RDB$TYPE_NAME                RDB$SYSTEM_FLAG
   ========= ============================ =================

           0 BINARY                                     1
           1 TEXT                                       1
           2 BLR                                        1
           3 ACL                                        1
           4 RANGES                                     1
           5 SUMMARY                                    1
           6 FORMAT                                     1
           7 TRANSACTION_DESCRIPTION                    1
           8 EXTERNAL_FILE_DESCRIPTION                  1
      

    declare filter pesh input_type 0 output_type 3
      entry_point 'f' module_name 'p';
      

    declare filter pesh input_type binary output_type acl
      entry_point 'f' module_name 'p';
      

  SQL> insert into rdb$types
  CON> values('RDB$FIELD_SUB_TYPE', -100, 'XDR', 'test type', 0);
  SQL> commit;
  SQL> declare filter pesh2 input_type xdr output_type text
  CON> entry_point 'p2' module_name 'p';
  SQL> show filter pesh2;
  BLOB Filter: PESH2
          Input subtype: -100 Output subtype: 1
          Filter library is p
          Entry point is p2
        

(v.2.1) Una espressione di tabella comune, in inglese common table expression o più brevemente CTE è come una vista definita localmente all'interno di una query principale. Il motore tratta una CTE come una tabella derivata e non viene effettuata nessuna materializzazione intermedia dei dati.

select :
  select_expr for_update_clause lock_clause
select_expr :
  with_clause select_expr_body order_clause rows_clause
            | select_expr_body order_clause rows_clause
with_clause :
  WITH RECURSIVE with_list | WITH with_list
with_list :
  with_item | with_item ',' with_list
with_item :
  symbol_table_alias_name derived_column_list
    AS '(' select_expr ')'
select_expr_body :
  query_term
  | select_expr_body UNION distinct_noise query_term
             | select_expr_body UNION ALL query_term
        

WITH [RECURSIVE]
	CTE_A [(a1, a2, …)]
	AS ( SELECT … ),

	CTE_B [(b1, b2, …)]
	AS ( SELECT … ),
...
SELECT ...
  FROM CTE_A, CTE_B, TAB1, TAB2 ...
 WHERE ...
        

WITH
  DEPT_YEAR_BUDGET AS (
    SELECT FISCAL_YEAR, DEPT_NO,
        SUM(PROJECTED_BUDGET) AS BUDGET
      FROM PROJ_DEPT_BUDGET
    GROUP BY FISCAL_YEAR, DEPT_NO
  )
SELECT D.DEPT_NO, D.DEPARTMENT,
  B_1993.BUDGET AS B_1993, B_1994.BUDGET AS B_1994,
       B_1995.BUDGET AS B_1995, B_1996.BUDGET AS B_1996
  FROM DEPARTMENT D
    LEFT JOIN DEPT_YEAR_BUDGET B_1993
      ON D.DEPT_NO = B_1993.DEPT_NO
      AND B_1993.FISCAL_YEAR = 1993
    LEFT JOIN DEPT_YEAR_BUDGET B_1994
      ON D.DEPT_NO = B_1994.DEPT_NO
      AND B_1994.FISCAL_YEAR = 1994
    LEFT JOIN DEPT_YEAR_BUDGET B_1995
      ON D.DEPT_NO = B_1995.DEPT_NO
      AND B_1995.FISCAL_YEAR = 1995
    LEFT JOIN DEPT_YEAR_BUDGET B_1996
      ON D.DEPT_NO = B_1996.DEPT_NO
      AND B_1996.FISCAL_YEAR = 1996

  WHERE EXISTS (
    SELECT * FROM PROJ_DEPT_BUDGET B
    WHERE D.DEPT_NO = B.DEPT_NO)
          

WITH RECURSIVE
  DEPT_YEAR_BUDGET AS
  (
    SELECT FISCAL_YEAR, DEPT_NO,
        SUM(PROJECTED_BUDGET) AS BUDGET
      FROM PROJ_DEPT_BUDGET
    GROUP BY FISCAL_YEAR, DEPT_NO
  ),

  DEPT_TREE AS
  (
    SELECT DEPT_NO, HEAD_DEPT, DEPARTMENT,
        CAST('' AS VARCHAR(255)) AS INDENT
      FROM DEPARTMENT
     WHERE HEAD_DEPT IS NULL

    UNION ALL

    SELECT D.DEPT_NO, D.HEAD_DEPT, D.DEPARTMENT,
    H.INDENT || '  '
      FROM DEPARTMENT D
      JOIN DEPT_TREE H
        ON D.HEAD_DEPT = H.DEPT_NO
  )

  SELECT D.DEPT_NO,
	D.INDENT || D.DEPARTMENT AS DEPARTMENT,
	B_1993.BUDGET AS B_1993,
	B_1994.BUDGET AS B_1994,
	B_1995.BUDGET AS B_1995,
	B_1996.BUDGET AS B_1996

  FROM DEPT_TREE D
    LEFT JOIN DEPT_YEAR_BUDGET B_1993
      ON D.DEPT_NO = B_1993.DEPT_NO
      AND B_1993.FISCAL_YEAR = 1993

    LEFT JOIN DEPT_YEAR_BUDGET B_1994
      ON D.DEPT_NO = B_1994.DEPT_NO
      AND B_1994.FISCAL_YEAR = 1994

    LEFT JOIN DEPT_YEAR_BUDGET B_1995
      ON D.DEPT_NO = B_1995.DEPT_NO
      AND B_1995.FISCAL_YEAR = 1995

    LEFT JOIN DEPT_YEAR_BUDGET B_1996
      ON D.DEPT_NO = B_1996.DEPT_NO
      AND B_1996.FISCAL_YEAR = 1996
          

(v.2.1) Questa funzione riporta una stringa che è il concatenamento di tutti i valori non NULL di un raggruppamento. Riporta NULL se non ci sono valori non-NULL.

Formato

<list function> ::=
  LIST '(' [ {ALL | DISTINCT} ] <espressione> [',' <delimitatore>
   ] ')'

<delimitatore> ::=
      { <stringa> | <parametro> | <variabile> }
    

Regole sintattiche

Altre note

Esempi

/* A */
  SELECT LIST(ID, ':')
  FROM MY_TABLE

/* B */
  SELECT TAG_TYPE, LIST(TAG_VALUE)
  FROM TAGS
  GROUP BY TAG_TYPE
      

(v.2.1) Lo scopo di questa clausola è quella di permettere al client di avere di ritorno dalle frasi di INSERT, UPDATE, UPDATE OR INSERT e DELETE i valori inseriti (o eliminati) in una tabella.

L'uso tipico è recuperare il valore generato per una chiave primaria dall'esecuzione di un trigger BEFORE. La clausola RETURNING è opzionale ed è disponibile sia in DSQL che in PSQL, sebbene ci siano leggere differenze nella sintassi.

In DSQL, l'esecuzione dell'operazione stessa ed il riporto dei valori avvengono una unico ciclo di esecuzione.

Poiché la clausola RETURNING è stata progettata per riportare un solo record di dati (singleton) in risposta all'esecuzione di una operazione su una singola registrazione, non è consentito specificare tale clausola nelle frasi che inseriscono, aggiornano o cancellano più di un record.

Regole sintattiche generali

INSERT INTO ... VALUES (...)
    [RETURNING <column_list> [INTO <variable_list>]]

INSERT INTO ... SELECT ...
    [RETURNING <column_list> [INTO <variable_list>]]

UPDATE OR INSERT INTO ... VALUES (...) ...
    [RETURNING <column_list> [INTO <variable_list>]]

UPDATE ... [RETURNING <column_list> [INTO <variable_list>]]

DELETE FROM ...
    [RETURNING <column_list> [INTO <variable_list>]]
      

(v.2.1) Questa sintassi è stata introdotto per poter inserire o aggiornare un record in funzione della sua effettiva esistenza (verificata con IS NOT DISTINCT). La frase è disponibili sia in DSQL che in PSQL.

Sintassi

UPDATE OR INSERT INTO <table or view> [(<column_list>)]
    VALUES (<value_list>)
    [MATCHING (<column_list>)]
    [RETURNING <column_list> [INTO <variable_list>]]
      

Esempi

(v.2.1) Questa sintassi è stata aggiunta per permettere di modificare o inserire un record se viene soddisfatta una certa condizione data. La frase è disponibile sia in DSQL che in PSQL.

Sintassi

<merge> ::=
MERGE
  INTO <tabella o vista> [ [AS] <nome di correlazione> ]
  USING <tabella o vista o tabella derivata> [ [AS] <nome di correlazione> ]
    ON <condizione>
    [ <merge quando soddisfatto> ]
    [ <merge quando non soddisfatto> ]

<merge quando soddisfatto> ::=
  WHEN MATCHED THEN
    UPDATE SET <lista assegnazioni>

<merge quando non soddisfatto> ::=
  WHEN NOT MATCHED THEN
    INSERT [ <parentesi aperta> <lista di colonne> <parentesi chiusa> ]
    VALUES <parentesi aperta> <lista di valori> <parentesi chiusa>
      

Esempio

MERGE INTO customers c
  USING (SELECT * FROM customers_delta WHERE id > 10) cd
  ON (c.id = cd.id)
    WHEN MATCHED THEN
      UPDATE SET
        name = cd.name
    WHEN NOT MATCHED THEN
      INSERT (id, name)
      VALUES (cd.id, cd.name)
      

(v.2.1) Sono stati introdotti due nuovi tipi di JOIN: la join NAMED COLUMNS (colonne in comune) e la join NATURAL.

<named columns join> ::=
  <table reference> <join type> JOIN <table reference>
    USING ( <column list> )

<natural join> ::=
 <table reference> NATURAL <join type> JOIN <table primary>
        

/* 1 */
select * from employee
  join department
  using (dept_no);

/* 2 */
select * from employee_project
  natural join employee
  natural join project;
        

   A CROSS JOIN B
        

   A INNER JOIN B ON 1 = 1
        

  FROM A, B
        

Richiesta di nuova specifica

(v.2.1) Adesso è possibile effettuare inserimenti senza specificare valori, se ci sono trigger BEFORE INSERT e/o defaults disponibili per ogni colonna necessaria e nessuno di questi dipende da un valore di campo NEW fornito dal comando standard. In soldoni, niente deve dipendere dalla parte VALUES(<lista di valori>).

Esempio

INSERT INTO <table>
  DEFAULT VALUES
  [RETURNING <values>]
      

(v.2.1) A vari livelli di gestione, il motore adesso tratta i BLOB di testo che contengono stringhe più corte di 32766 byte come se fossero di tipo VARCHAR. La lunghezza massima per questa conversione implicita è pertanto 32765 bytes (non caratteri!).

Le operazioni che permettono ai BLOB di testo di comportarsi come stringhe VARCHAR sono le assegnazioni, conversioni e concatenazioni (fino al limite sopra specificato per il risultato della concatenazione), così come le funzioni CAST, LOWER, UPPER, TRIM e SUBSTRING.

(v.2.0.x) Si possono effettuare comparazioni sull'intero contenuto di un BLOB di testo.

Richiesta CORE-979

(v.2.1) Per qualche anomalia, la RDB$DB_KEY fisica ha sempre riportato un valore in ogni riga quando si specifica una OUTER JOIN, pertanto effettuando un test su quei valori dove ci si aspetterebbe un NULL per mancanza di corrispondenza, nelle versioni precedenti il test avrebbe riportato un risultato errato (rovesciato: falso al posto di vero). Ora, RDB$DB_KEY riporta correttamente NULL quando dovrebbe.

(v.2.1) Nelle prime pre-release di Firebird 2.1, sono stati introdotti controlli per rifiutare gli ordinamenti (nelle operazioni di ORDER BY, GROUP BY e SELECT DISTINCT) al momento della preparazione se la clausola di ordinamento implicitamente o esplicitamente implicava il sort su una colonna di tipo BLOB o ARRAY.

Questa modifica è stata eliminata nella pre-release RC2, non perché sbagliata ma perché molti utenti si sono lamentati che le loro applicazioni non funzionavano più.

(v.2.1) Sono state migliorate alcune delle funzioni integrate esistenti, e ne sono state aggiunte un bel po'.

Alcune migliorie alle funzioni integrate erano già disponibili nelle versioni 2.0.x di Firebird:

   IIF (<condizione_di_ricerca>, <valore_se_vero>, <valore_altrimenti>)
        

   CASE
     WHEN <condizione_di_ricerca> THEN <valore_se_vero>
     ELSE <valore_altrimenti>
   END
        

    SELECT IIF(VAL > 0, VAL, -VAL) FROM OPERATION
        

  SELECT CAST(? AS INT) FROM RDB$DATABASE
        

La gestione degli alias e la ricerca dei nomi di campo ambigui è stata migliorata. In sostanza:

Esempi

EXECUTE BLOCK è un'estensione al linguaggio SQL che permette l'uso del "PSQL dinamico" all'interno di una SELECT. Ha l'effetto di ottenere un blocco di codice PSQL autocontenuto in modo da essere eseguito in una SQL dinamico come se fosse una STORED PROCEDURE.

Sintassi

   EXECUTE BLOCK [ (param datatype = ?, param datatype = ?, ...) ]
     [ RETURNS (param datatype, param datatype, ...) ]
   AS
   [DECLARE VARIABLE var datatype; ...]
   BEGIN
     ...
   END
      

Per il client, la chiamata isc_dsql_sql_info col parametro isc_info_sql_stmt_type riporta

Il client deve preprocessare solo la testata dello statement SQL oppure usare '? invece di ':' come indicatore di parametro, perché, nel corpo del blocco, potrebbero esserci riferimenti a variabili locali o ad argomenti con il prefisso ':' .

Esempio

Se il comando SQL da usare è

   EXECUTE BLOCK (X INTEGER = :X)
     RETURNS (Y VARCHAR)
   AS
   DECLARE V INTEGER;
   BEGIN
     INSERT INTO T(...) VALUES (... :X ...);
     SELECT ... FROM T INTO :Y;
     SUSPEND;
   END
      

Il comando SQL preprocessato deve essere

   EXECUTE BLOCK (X INTEGER = ?)
     RETURNS (Y VARCHAR)
   AS
   DECLARE V INTEGER;
   BEGIN
     INSERT INTO T(...) VALUES (... :X ...);
     SELECT ... FROM T INTO :Y;
     SUSPEND;
   END
      

Il supporto per le tabelle derivate in DSQL (che sono sottoquery poste nella clausola FROM) è stato aggiunto come definito nello standard SQL200X. Una tabella derivata è un insieme di righe ottenute da una frase SELECT dinamica. Le tabelle derivate possono essere innestate, se necessario, per costruire complesse query e possono far parte di JOIN come se fossero normali tabelle o viste.

Sintassi

    SELECT
      <elenco di selezioni>
    FROM
      <elenco riferimenti tabellari>

    <elenco riferimenti tabellari> ::= <riferimento tabellare> [{<virgola> <riferimento tabellare>}...]

    <riferimento tabellare> ::=
        <tabella primaria>
      | <tabella di join>

    <tabella primaria> ::=
        <tabella> [[AS] <pseudonimo>]
      | <tabella derivata>

    <tabella derivata> ::=
        <espressione query> [[AS] <pseudonimo>]
          [<parentesi aperta> <elenco di colonne derivate> <parentesi chiusa>]

    <elenco di colonne derivate> ::= <nome colonna> [{<virgola> <nome colonna>}...]
      

Esempi

a) Tabella derivata semplice:

  SELECT
    *
  FROM
    (SELECT
       RDB$RELATION_NAME, RDB$RELATION_ID
     FROM
       RDB$RELATIONS) AS R (RELATION_NAME, RELATION_ID)
      

b) Aggregazione su una tabella derivata che contiene a sua volta un aggregato

  SELECT
    DT.FIELDS,
    Count(*)
  FROM
    (SELECT
       R.RDB$RELATION_NAME,
       Count(*)
     FROM
       RDB$RELATIONS R
       JOIN RDB$RELATION_FIELDS RF ON (RF.RDB$RELATION_NAME = R.RDB$RELATION_NAME)
     GROUP BY
       R.RDB$RELATION_NAME) AS DT (RELATION_NAME, FIELDS)
  GROUP BY
    DT.FIELDS
      

c) Esempio con UNION e ORDER BY:

  SELECT
    DT.*
  FROM
    (SELECT
       R.RDB$RELATION_NAME,
       R.RDB$RELATION_ID
     FROM
       RDB$RELATIONS R
     UNION ALL
     SELECT
       R.RDB$OWNER_NAME,
       R.RDB$RELATION_ID
     FROM
       RDB$RELATIONS R
     ORDER BY
       2) AS DT
  WHERE
    DT.RDB$RELATION_ID <= 4
      

Note essenziali

In DSQL adesso è supportata anche la frase ROLLBACK RETAIN.

Il «rollback retaining» era stato introdotto in InterBase 6.0, ma questa modalità di rollback poteva essere usata solo attraverso una chiamata API: la isc_rollback_retaining(). Invece, il «commit retaining» poteva essere invocato sia con la chiamata API isc_commit_retaining(), sia usando il comando DSQL COMMIT RETAIN.

Firebird 2.0 aggiunge una clausola opzionale RETAIN alla comando DSQL ROLLBACK per renderlo consistente al COMMIT [RETAIN].

La sintassi: è simile a quella del COMMIT RETAIN.

La sintassi ROWS si usa per limitare il numero di righe riportate da un'espressione di selezione. Viene applicata alla fine di una frase di SELECT di livello principale, e specifica il numero di righe da riportare al programma principale. Di fatto costituisce un'alternativa meglio comprensibile alle clausole FIRST/SKIP, e, oltre ad essere in accordo con lo standard SQL più recente, la sintassi ROWS da' alcuni benefici extra. Può infatti essere usata nelle UNION, in ogni tipo di subquery e nelle frasi UPDATE o DELETE.

Disponibile sia in DSQL che in PSQL.

Sintassi

   SELECT ...
     [ORDER BY <expr_list>]
     ROWS <expr1> [TO <expr2>]
      

Esempi

1.

  SELECT * FROM T1
    UNION ALL
  SELECT * FROM T2
    ORDER BY COL
    ROWS 10 TO 100
      

2.

   SELECT COL1, COL2,
     ( SELECT COL3 FROM T3 ORDER BY COL4 DESC ROWS 1 )
   FROM T4
      

3.

   DELETE FROM T5
     ORDER BY COL5
     ROWS 1
      

Note essenziali

Le regole per le query UNION sono state migliorate come segue:

  UNION [{DISTINCT | ALL}]
        

Sono state aggiunte le seguenti caratteristiche che riguardano la gestione del NULL in DSQL:

   <valore> IS [NOT] DISTINCT FROM <valore>
        

   SELECT * FROM T1
     JOIN T2
       ON T1.NAME IS NOT DISTINCT FROM T2.NAME;
        

   SELECT * FROM T
     WHERE T.MARK IS DISTINCT FROM 'test';
        

  A = NULL
  B > NULL
  A + NULL
  B || NULL
        

  Database:  proc.fdb
  SQL> create table gnull(a int);
  SQL> insert into gnull values(null);
  SQL> insert into gnull values(1);
  SQL> select a from gnull order by a;
             A
  ============
        <null>
             1

  SQL> select a from gnull order by a asc;

             A
  ============
        <null>
             1

  SQL> select a from gnull order by a desc;

             A
  ============
             1
        <null>

  SQL> select a from gnull order by a asc nulls first;

             A
  ============
        <null>
             1

  SQL> select a from gnull order by a asc nulls last;

             A
  ============
             1
        <null>


  SQL> select a from gnull order by a desc nulls last;

             A
  ============
             1
        <null>

  SQL> select a from gnull order by a desc nulls first;

             A
  ============
        <null>
             1
        

Le specifiche di una SELECT nelle subquery e nelle frasi INSERT INTO <specifica-di-insert> SELECT... possono ora specificare anche insiemi UNION.

Le specifiche di ROWS e le clausole PLAN e ORDER BY possono ora essere usate nelle frasi di UPDATE e di DELETE.

Gli utenti possono ora definire PLAN specifici per le frasi di UPDATE e di DELETE in modo da ottimizzarle a mano. Inoltre è possibile limitare il numero dei record influenzati dalla direttiva con una clausola ROWS, opzionalmente usata in combinazione con una clausola ORDER BY per ottenere un insieme di registrazioni ordinato.

Sintassi

  UPDATE ... SET ... WHERE ...
  [PLAN <elementi di plan>]
  [ORDER BY <lista elementi ordinamento>]
  [ROWS <valnum-1> [TO <valnum-2>]]
      

or

  DELETE ... FROM ...
  [PLAN <elementi di plan>]
  [ORDER BY <lista elementi ordinamento>]
  [ROWS <valnum-1> [TO <valnum-2>]]
      

Un certo numero di caratteristiche sono state aggiunte per estendere le informazioni di contesto che possono essere gestite:

    CURRENT_TIME [(<precisione>)]
    CURRENT_TIMESTAMP [(<precisione>)]
          

    1. SELECT CURRENT_TIME FROM RDB$DATABASE;
    2. SELECT CURRENT_TIME(3) FROM RDB$DATABASE;
    3. SELECT CURRENT_TIMESTAMP(3) FROM RDB$DATABASE;
          

    RDB$SET_CONTEXT( <namespace>, <variabile>, <valore> )
    RDB$GET_CONTEXT( <namespace>, <variabile> )
       

  DECLARE EXTERNAL FUNCTION RDB$GET_CONTEXT
      VARCHAR(80),
      VARCHAR(80)
  RETURNS VARCHAR(255) FREE_IT;

  DECLARE EXTERNAL FUNCTION RDB$SET_CONTEXT
      VARCHAR(80),
      VARCHAR(80),
      VARCHAR(255)
  RETURNS INTEGER BY VALUE;
       

   set term ^;
   create procedure set_context(User_ID varchar(40), Trn_ID integer) as
   begin
     RDB$SET_CONTEXT('USER_TRANSACTION', 'Trn_ID', Trn_ID);
     RDB$SET_CONTEXT('USER_TRANSACTION', 'User_ID', User_ID);
   end ^

  create table journal (
     jrn_id integer not null primary key,
     jrn_lastuser varchar(40),
     jrn_lastaddr varchar(255),
     jrn_lasttransaction integer
  )^

CREATE TRIGGER UI_JOURNAL FOR JOURNAL BEFORE INSERT OR UPDATE
  as
  begin
    new.jrn_lastuser = rdb$get_context('USER_TRANSACTION', 'User_ID');
    new.jrn_lastaddr = rdb$get_context('SYSTEM', 'CLIENT_ADDRESS');
    new.jrn_lasttransaction = rdb$get_context('USER_TRANSACTION', 'Trn_ID');
  end ^
  commit ^
  execute procedure set_context('skidder', 1) ^

  insert into journal(jrn_id) values(0) ^
  set term ;^
          

  SQL> select rdb$set_context('USER_SESSION', 'Nickolay', 'ru')
  CNT> from rdb$database;

  RDB$SET_CONTEXT
  ===============
                0
          

  SQL> select rdb$set_context('USER_SESSION', 'Nickolay', 'ca')
  CNT> from rdb$database;

  RDB$SET_CONTEXT
  ===============
                1
          

  SQL> select rdb$set_context('USER_SESSION', 'Nickolay', NULL)
  CNT> from rdb$database;

  RDB$SET_CONTEXT
  ===============
                1
          

  SQL> select rdb$set_context('USER_SESSION', 'Nickolay', NULL)
  CNT> from rdb$database;

  RDB$SET_CONTEXT
  ===============
                0
          

Regole sintattiche

Lo schema seguente descrive le regole sintattiche per la clausola PLAN per essere d'aiuto nella loro stesura.

PLAN ( { <stream_retrieval> | <sorted_streams> | <joined_streams> } )

<stream_retrieval> ::= { <natural_scan> | <indexed_retrieval> |
    <navigational_scan> }

<natural_scan> ::= <stream_alias> NATURAL

<indexed_retrieval> ::= <stream_alias> INDEX ( <index_name>
    [, <index_name> ...] )

<navigational_scan> ::= <stream_alias> ORDER <index_name>
    [ INDEX ( <index_name> [, <index_name> ...] ) ]

<sorted_streams> ::= SORT ( <stream_retrieval> )

<joined_streams> ::= JOIN ( <stream_retrieval>, <stream_retrieval>
    [, <stream_retrieval> ...] )
    | [SORT] MERGE ( <sorted_streams>, <sorted_streams> )
      

Dettagli

Natural scan (scansione naturale) significa che tutte le righe vengono recuperate nell'ordine naturale di memorizzazione. Pertanto bisogna leggere tutte le pagine prima di poter validare un criterio di ricerca.

Indexed retrieval (accesso indicizzato) usa un particolare metodo indicizzato (range index scan) per trovare le righe che concordano con il criterio di ricerca dato. Le corrispondenze trovate sono combinate in una «mappa di bit sparsi» (sparse bitmap) che viene ordinata per numeri di pagina, in modo da dover leggere una pagina solo una volta. Dopo di ché le pagine dei dati vengono lette e da esse si recuperano le righe richieste.

Navigational scan (scansione in ordine) utilizza un indice per riportare le righe in certo ordine, se si può effettuare una tale operazione.

Una operazione di SORT (sort operation) effettua un ordinamento esterno del flusso di dati recuperato.

Una operazione di JOIN può essere effettuata sia attraverso un algoritmo ciclico innestato (JOIN plan) oppure con un algoritmo di sort merge (MERGE plan).

Un sort merge (ordina e riunisce) opera su due flussi in ingresso che sono dapprima ordinati e poi riuniti in una unica esecuzione.

Esempi

    SELECT RDB$RELATION_NAME
    FROM RDB$RELATIONS
    WHERE RDB$RELATION_NAME LIKE 'RDB$%'
    PLAN (RDB$RELATIONS NATURAL)
    ORDER BY RDB$RELATION_NAME

    SELECT R.RDB$RELATION_NAME, RF.RDB$FIELD_NAME
    FROM RDB$RELATIONS R
      JOIN RDB$RELATION_FIELDS RF
      ON R.RDB$RELATION_NAME = RF.RDB$RELATION_NAME
    PLAN MERGE (SORT (R NATURAL), SORT (RF NATURAL))
      

Note

Nelle operazioni di ordinamento sono stati fatti alcuni utili sviluppi:

  ...
    GROUP BY
    SUBSTRING(CAST((A * B) / 2 AS VARCHAR(15)) FROM 1 FOR 2)
        

   SELECT *
     FROM RDB$RELATIONS
     ORDER BY 9
        

L'espressione NEXT VALUE FOR <sequence_name> conforme a SQL-99 è stata aggiunta come sinonimo di GEN_ID(<generator-name>, 1), integrando l'inserimento della sintassi SQL standard CREATE SEQUENCE come equivalente di CREATE GENERATOR.

Esempi

1.

   SELECT GEN_ID(S_EMPLOYEE, 1) FROM RDB$DATABASE;
      

2.

   INSERT INTO EMPLOYEE (ID, NAME)
     VALUES (NEXT VALUE FOR S_EMPLOYEE, 'John Smith');
      

La semantica

Regole sintattiche

  <frase di select> ::=
    <espressione di select> [FOR UPDATE] [WITH LOCK]

  <espressione di select> ::=
    <specifiche di query> [UNION [{ALL | DISTINCT}] <specifiche di query>]

  <specifiche di query> ::=
    SELECT [FIRST <valore>] [SKIP <valore>] <lista di selezione>
    FROM <lista di espressioni tabellari>
    WHERE <condizioni di ricerca>
    GROUP BY <lista valori di raggruppamento>
    HAVING <condizioni di raggruppamento>
    PLAN <lista di elementi PLAN>
    ORDER BY <lista di valori per l'ordinamento>
    ROWS <value> [TO <value>]

  <espressione tabellare> ::=
    <nome tabella> | <tabella in join> | <tabella derivata>

  <tabella in join> ::=
    {<cross join> | <qualified join>}

  <cross join> ::=
    <espressione tabellare> CROSS JOIN <espressione tabellare>

  <qualified join> ::=
    <espressione tabellare> [{INNER | {LEFT | RIGHT | FULL} [OUTER]}] JOIN <espressione tabellare>
    ON <join condition>

  <tabella derivata> ::=
    '(' <espressione di select> ')'
    

Conclusioni

Note

Quando si effettua un'aggregazione per generare colonne con CASE o UNION con una miscela di tipi di dato compatibili, il motore deve scegliere un singolo tipo di dato per il risultato di ogni colonna. Chi sviluppa deve spesso preparare una variabile per depositarvi il risultato e può essere disorientato se avviene un'eccezione sul tipo di dato. Le seguenti regole sono quelle seguite per determinare il tipo di dato scelto dal motore per i valori di una colonna in tali condizioni.

Nel passato, prima dell'avvento delle variabili di contesto come CURRENT_DATE, CURRENT_TIMESTAMP, ecc. , si usavano delle convenzionali stringhe letterali predefinite (predefined date literals), come 'NOW', 'TODAY', 'YESTERDAY' e così via. Queste letterali predefinite sono sopravvissute nel linguaggio SQL attuale di Firebird e sono ancora molto utili.

In Interbase 5.x e precedenti, la seguente frase era «legale» e riportava un valore di tipo DATE ( ricordare che allora il tipo DATE era ciò che adesso è il tipo TIMESTAMP):

select 'NOW' from rdb$database /* riporta data ed ora di sistema */
          

In un database con ODS 10 o superiore, quella frase riporta solo la stringa 'NOW'. Bisogna pertanto forzare il tipo del dato con CAST per ottenere adesso il risultato voluto:

select cast('NOW' as TIMESTAMP) from rdb$database
          

Per molto tempo, probabilmente già da IB 6, c'è stata una non documentata «sintassi abbreviata» per forzare qualsiasi letterale, non solo quelli di data ed ora. Attualmente, è definito nello standard. Molti di noi semplicemente non sapevano di questa possibilità. Questa sintassi ha la forma <tipo-di-dato> <letterale>. Con l'esempio di CAST precedente in mente, l'espressione sintattica abbreviata è:

select TIMESTAMP 'NOW' from rdb$database
          

Questo tipo di sintassi abbreviata può essere utilizzata anche in altri modi. L'esempio seguente mostra un'operazione aritmetica sulle date con un letterale predefinito:

update mytable
  set OVERDUE = 'T'
  where DATE 'YESTERDAY' - DATE_DUE > 10
          

(V.2.1) Ora è possibile usare un dominio per dichiarare il tipo di dato degli argomenti e delle variabili nei moduli PSQL. In funzione dell'esigenza, si può dichiarare un argomento o una variabile usando in alternativa:

Sintassi

data_type ::=
    <builtin_data_type>
    | <domain_name>
    | TYPE OF <domain_name>
      

Esempi

CREATE DOMAIN DOM AS INTEGER;

CREATE PROCEDURE SP (
  I1 TYPE OF DOM,
  I2 DOM)
RETURNS (
  O1 TYPE OF DOM,
  O2 DOM)
AS
  DECLARE VARIABLE V1 TYPE OF DOM;
  DECLARE VARIABLE V2 DOM;

BEGIN
  ...
END
      

(V.2.1) Alle variabili PSQL e agli argomenti delle procedure, possono essere applicati gli ordinamenti (collazioni).

Richiesta CORE-1213

(V.2.1) L'operatore sui cursori WHERE CURRENT OF può percorrere un cursore su un record set di una vista, come se fosse il cursore sul risultato di una SELECT su una tabella. Ad esempio:

...
FOR SELECT ...
   FROM MY_VIEW INTO ... AS CURSOR VIEW_CURSOR DO
BEGIN
  ...
  DELETE FROM MY_VIEW
    WHERE CURRENT OF VIEW_CURSOR;
  ...
END
      

ROW_COUNT è stata migliorata in modo tale che adesso riporta il numero di record recuperati da una frase SELECT.

Per esempio, può essere usata per verificare se una SELECT INTO ha effettivamente assegnato qualcosa:

  ..
  BEGIN
    SELECT COL FROM TAB INTO :VAR;

    IF (ROW_COUNT = 0) THEN
      EXCEPTION NO_DATA_FOUND;
  END
  ..
      

Vedere anche gli esempi più oltre sull'uso dei cursori espliciti in PSQL.

In PSQL si possono ora dichiarare ed usare cursori multipli. I cursori espliciti sono disponibili anche nelle strutture DSQL EXECUTE BLOCK oltre che nelle STORED PROCEDURE e nei TRIGGER.

Sintassi

    DECLARE [VARIABLE] <cursor_name> CURSOR FOR ( <select_statement> );
    OPEN <cursor_name>;
    FETCH <cursor_name> INTO <var_name> [, <var_name> ...];
    CLOSE <cursor_name>;
      

Esempi

1.

  DECLARE RNAME CHAR(31);
  DECLARE C CURSOR FOR ( 
    SELECT RDB$RELATION_NAME
    FROM RDB$RELATIONS 
  );
  BEGIN
    OPEN C;
    WHILE (1 = 1) DO
    BEGIN
      FETCH C INTO :RNAME;
      IF (ROW_COUNT = 0) THEN
        LEAVE;
      SUSPEND;
    END
    CLOSE C;
  END
      

2.

  DECLARE RNAME CHAR(31);
  DECLARE FNAME CHAR(31);
  DECLARE C CURSOR FOR (
    SELECT RDB$FIELD_NAME
    FROM RDB$RELATION_FIELDS
    WHERE RDB$RELATION_NAME = :RNAME
    ORDER BY RDB$FIELD_POSITION
  );
  BEGIN
    FOR
      SELECT RDB$RELATION_NAME
      FROM RDB$RELATIONS
      INTO :RNAME
    DO
    BEGIN
      OPEN C;
      FETCH C INTO :FNAME;
      CLOSE C;
      SUSPEND;
    END
  END
      

Si possono dichiarare valori di default per gli argomenti delle STORED PROCEDURE.

La sintassi è identica alla definizione di un valore default per una colonna o per un dominio, eccetto che si può usare '=' al posto della parola chiave 'DEFAULT'.

Gli argomenti con valori di default devono venire per ultimi nella lista degli argomenti; cioè non si può dichiarare un argomento che non ha un default dopo un argomento che è stato dichiarato con un valore di default. Il chiamante deve comunque fornire tutti gli argomenti precedenti a quelli di cui vuole adoperare il proprio default.

Pertanto non si possono fare cose come fornire il gli primo e secondo argomento, non fornire il terzo argomento e fornire il quarto...

La sostituzione dei valori di default avviene durante l'esecuzione. Se è definita una procedura con default P1 e la si chiama da un'altra procedura P2 saltando alcuni dei parametri finali che hanno il default, allora i valori di default per P1 verranno sostituiti dal motore solo al momento in cui inizia l'esecuzione di P1. Questo significa che, cambiando i valori di default non è necessario ricompilare P2.

Tuttavia è sempre necessario scollegare tutte le connessioni client, come è descritto nel Borland InterBase 6 beta "Data Definition Guide" (DataDef.pdf), nella sezione "Altering and dropping procedures in use".

Esempi

   CONNECT ... ;
   SET TERM ^;
   CREATE PROCEDURE P1 (X INTEGER = 123)
   RETURNS (Y INTEGER)
   AS
   BEGIN
     Y = X;
     SUSPEND;
   END ^
   COMMIT ^
   SET TERM ;^

   SELECT * FROM P1;

              Y
   ============

            123

   EXECUTE PROCEDURE P1;

              Y
   ============
            123

   SET TERM ^;
   CREATE PROCEDURE P2
   RETURNS (Y INTEGER)
   AS
   BEGIN
     FOR SELECT Y FROM P1 INTO :Y
     DO SUSPEND;
   END ^
   COMMIT ^
   SET TERM ;^

   SELECT * FROM P2;

              Y
   ============

            123

   SET TERM ^;
   ALTER PROCEDURE P1 (X INTEGER = CURRENT_TRANSACTION)
            RETURNS (Y INTEGER)
   AS
   BEGIN
     Y = X;
    SUSPEND;
   END; ^
   COMMIT ^
   SET TERM ;^

   SELECT * FROM P1;

              Y
   ============

           5875

   SELECT * FROM P2;

              Y
   ============

            123

   COMMIT;

   CONNECT  ... ;

   SELECT * FROM P2;

              Y
   ============

           5880

      

La nuova sintassi LEAVE <label> permette di marcare i cicli PSQL con etichette e di uscirne in modo simile al linguaggio Java. Lo scopo è quello di terminare l'esecuzione del blocco corrente e riprendere dall'etichetta specificata. Dopodiché l'esecuzione prosegue dalla frase immediatamente successiva al ciclo terminato.

Sintassi

    <nome_etichetta>: <ciclo>
    ...
    LEAVE [<nome_etichetta>]
      

dove <ciclo> è uno fra: WHILE, FOR SELECT, FOR EXECUTE STATEMENT.

Esempi

1.

   FOR
     SELECT COALESCE(RDB$SYSTEM_FLAG, 0), RDB$RELATION_NAME
       FROM RDB$RELATIONS
       ORDER BY 1
     INTO :RTYPE, :RNAME
     DO
     BEGIN
       IF (RTYPE = 0) THEN
         SUSPEND;
       ELSE
         LEAVE; -- esce dal ciclo corrente
     END
      

2.

   CNT = 100;
   L1:
   WHILE (CNT >= 0) DO
   BEGIN
     IF (CNT < 50) THEN
       LEAVE L1; -- esce dal ciclo WHILE
     CNT = CNT - l;
   END
      

3.

   STMT1 = 'SELECT RDB$RELATION_NAME FROM RDB$RELATIONS';
   L1:
   FOR
     EXECUTE STATEMENT :STMT1 INTO :RNAME
   DO
   BEGIN
     STMT2 = 'SELECT RDB$FIELD_NAME FROM RDB$RELATION_FIELDS
       WHERE RDB$RELATION_NAME = ';
     L2:
     FOR
       EXECUTE STATEMENT :STMT2 || :RNAME INTO :FNAME
     DO
     BEGIN
       IF (RNAME = 'RDB$DATABASE') THEN
         LEAVE L1; -- esce dal ciclo esterno
       ELSE IF (RNAME = 'RDB$RELATIONS') THEN
         LEAVE L2; -- esce dal ciclo interno
       ELSE
         SUSPEND;
     END
   END
      

L'insieme delle variabili di contesto OLD disponibili nei trigger sono ora in sola lettura. Un tentativo di assegnare un valore a OLD.QUALUNQUECAMPO viene rifiutato.

Le API client possono ora estrarre un semplice stack trace dallo Status Vector di errore quando avviene un'eccezione nell'esecuzione di un PSQL (stored procedure o trigger). Uno stack trace è rappresentato da ina stringa (massimo 2048 byte) e consiste di tutti i nomi di STORED PROCEDURE e TRIGGER, a partire dal punto in cui è avvenuta l'eccezione, risalendo fino alla chiamata più esterna. Se la traccia è più lunga di quanto specificato al momento viene troncata.

Elementi aggiuntivi sono in coda allo Status Vector come segue:

   isc_stack_trace, isc_arg_string, <string length>, <string>
      

isc_stack_trace è un nuovo codice di errore con valore 335544842L.

Esempi

Creazione di metdata:

  CREATE TABLE ERR (
    ID INT NOT NULL PRIMARY KEY,
    NAME VARCHAR(16));

  CREATE EXCEPTION EX '!';
  SET TERM ^;

  CREATE OR ALTER PROCEDURE ERR_1 AS
  BEGIN
    EXCEPTION EX 'ID = 3';
  END ^

  CREATE OR ALTER TRIGGER ERR_BI FOR ERR
    BEFORE INSERT AS
  BEGIN
    IF (NEW.ID = 2)
    THEN EXCEPTION EX 'ID = 2';

    IF (NEW.ID = 3)
    THEN EXECUTE PROCEDURE ERR_1;

    IF (NEW.ID = 4)
    THEN NEW.ID = 1 / 0;
  END ^

  CREATE OR ALTER PROCEDURE ERR_2 AS
  BEGIN
    INSERT INTO ERR VALUES (3, '333');
  END ^
      

1. Eccezione utente da un trigger:

  SQL" INSERT INTO ERR VALUES (2, '2');
  Statement failed, SQLCODE = -836
  exception 3
  -ID = 2
  -At trigger 'ERR_BI'
      

2. Eccezione utente da una procedura chiamata da un trigger:

  SQL" INSERT INTO ERR VALUES (3, '3');
  Statement failed, SQLCODE = -836
  exception 3
  -ID = 3
  -At procedure 'ERR_1'
  At trigger 'ERR_BI'
      

3. Eccezione in esecuzione in un trigger (divisione per zero):

  SQL" INSERT INTO ERR VALUES (4, '4');
  Statement failed, SQLCODE = -802
  arithmetic exception, numeric overflow, or string truncation
  -At trigger 'ERR_BI'
      

4. Eccezione utente da una procedura:

  SQL" EXECUTE PROCEDURE ERR_1;
  Statement failed, SQLCODE = -836
  exception 3
  -ID = 3
  -At procedure 'ERR_1'
      

5. Eccezione utente da una procedura ad un livello più profondo dello stack:

  SQL" EXECUTE PROCEDURE ERR_2;
  Statement failed, SQLCODE = -836
  exception 3
  -ID = 3
  -At procedure 'ERR_1'
  At trigger 'ERR_BI'
  At procedure 'ERR_2'
      

In PSQL, le UDF supportate, ad esempio RDB$SET_CONTEXT, possono essere chiamate come se fossero funzioni che non riportano nulla, come le «procedure» dell'Object Pascal. Ad esempio:

  BEGIN
     ...
     RDB$SET_CONTEXT('USER_TRANSACTION', 'MY_VAR', '123');
     ...
  END
      

Il primo gruppo di modifiche influenza versione ODS del database, inclusi pertanto quelli non ancora aggiornati alla ODS 11.x.

        (NOT NOT A = 0) -> (A = 0)
        (NOT A > 0) -> (A <= 0)
          

  select rdb$relation_id, count(*)
  from rdb$relations
  group by rdb$relation_id
  having rdb$relation_id > 10

  select * from ( 
    select rdb$relation_id, count(*)
    from rdb$relations
    group by rdb$relation_id
    ) as grp (id, cnt)
  where grp.id > 10
          

Questo gruppo di ottimizzazioni influenza solo i database creati o recuperati in sotto Firebird 2 o successivi.

Il codice, in parte nuovo ed in parte rifatto, che gestisce gli indici è molto più veloce e tollera un gran numero di duplicazioni. Il vecchio limite per le chiavi aggregate di 252 bytes è stato rimosso. Ora il limite dipende dalla dimensione della pagina: la dimensione massima della chiave in byte è 1/4 della dimensione della pagina (512 su 2048, 1024 su 4096, ecc.)

Un numero di record a 40-bit viene incluso nei rami («non leaf-level pages») ed i duplicati nelle chiavi sono ordinati secondo questo numero.

Si possono indicizzare le righe attraverso espressioni arbitrarie in DDL dinamico applicate ai valori della riga, permettendo ai predicati di ricerca percorsi di accesso basati su espressioni.

Sintassi

CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]] INDEX <nome indice>
  ON <nome tabella>
  COMPUTED BY ( <espressione> )
        

Esempi

1.

CREATE INDEX IDX1 ON T1
  COMPUTED BY ( UPPER(COL1 COLLATE PXW_CYRL) );
COMMIT;
/*  */
SELECT * FROM T1
  WHERE UPPER(COL1 COLLATE PXW_CYRL) = 'ÔÛÂÀ'
-- PLAN (T1 INDEX (IDX1))
        

2.

CREATE INDEX IDX2 ON T2
  COMPUTED BY ( EXTRACT(YEAR FROM COL2) || EXTRACT(MONTH FROM COL2) );
COMMIT;
/*  */
SELECT * FROM T2
  ORDER BY EXTRACT(YEAR FROM COL2) || EXTRACT(MONTH FROM COL2)
-- PLAN (T2 ORDER IDX2)
        

L'algoritmo che comprime gli indici è stato completamente rifatto migliorando grandemente le prestazioni di moltissime query.

Le selettività degli indici sono ora memorizzate per ogni segmento. Questo significa che per un indice composito sulle colonne (A, B, C), vengono calcolati tre indici di selettività, che riflettono sia un riscontro totale sull'indice che tutti i parziali. Sarebbe a dire che la selettività dell'indice multi segmento coinvolge sia quella del solo segmento A (come sarebbe se ci fosse un indice a segmento unico), dei segmenti A e B insieme (come sarebbe se ci fosse in indice con segmento doppio) ed il riscontro con tutti e tre i segmenti (A, B, C); praticamente in tutti i modi si possa usare un indice composto.

Questo lascia più opportunità all'ottimizzatore per migliori decisioni sui percorsi da utilizzare nei casi in cui si cerchino riscontri su indici parziali.

I valori di selettività per segmento sono memorizzati nella colonna RDB$STATISTICS della tabella RDB$INDEX_SEGMENTS. La colonna con lo stesso nome in RDB$INDICES è mantenuta per sola compatibilità e tuttora rappresenta l'indice di selettività totale, che viene usato per un riscontro su tutto l'indice.

Firebird permette di definire il set di caratteri e l'ordinamento in qualsiasi dichiarazione di campo o variabile a caratteri. Il set di caratteri di default può essere inoltre specificato al momento della creazione del database, in modo che ogni dichiarazione CHAR o VARCHAR usi quel default se non include una specifica clausola CHARACTER SET.

Alla connessione normalmente si specifica il set di caratteri che il client intende usare per leggere le stringhe. Se non viene specificato un set di caratteri "client" (o di "connessione"), si impone il set di caratteri NONE.

Due speciali set di caratteri, NONE e OCTETS, possono essere utilizzati nelle dichiarazioni. Tuttavia, OCTETS non può essere specificato per le connessioni. I due set sono simili, tranne che per NONE il carattere spazio è ASCII 0x20, mentre per OCTETS è 0x00.

NONE e OCTETS sono «speciali» nel senso che usano nelle conversioni regole differenti da quelle degli altri set di caratteri.

I miglioramenti apportati da questo nuovo sistema includono:

  isql -q -ch dos850
  SQL> create database 'test.fdb';
  SQL> create table t (c char(1) character set dos850);
  SQL> insert into t values ('a');
  SQL> insert into t values ('e');
  SQL> insert into t values ('á');
  SQL> insert into t values ('é');
  SQL>
  SQL> select c, upper(c) from t;

  C      UPPER
  ====== ======
       a      A
       e      E
       á      á
       é      é
        

  C      UPPER
  ====== ======
       a      A
       e      E
       á      Á
       é      É
        

  select blob_column from table
    where blob_column collate unicode = 'foo';
          

I set di caratteri e gli ordinamenti sono installati usando un manifest file (documento di configurazione in formato particolare).

Il manifest file deve essere messo nel sottodirettorio intl dell'installazione (cioè $rootdir/intl in Linux o C:\Programmi\Firebird\Firebird_2_1\intl in Windows) con l'estensione .conf. Viene usato per trovare i set di caratteri e gli ordinamenti nelle librerie. Se un set di caratteri o un ordinamento sono elencati più di una volta, non viene caricato e viene inserito un errore nel log.

Il file /intl/fbintl.conf è un esempio di manifest file da cui sono state estratte le righe seguenti:

   <intl_module fbintl>
       filename    $(this)/fbintl
   </intl_module>

   <charset ISO8859_1>
       intl_module    fbintl
       collation    ISO8859_1
       collation    DA_DA
       collation    DE_DE
       collation    EN_UK
       collation    EN_US
       collation    ES_ES
       collation    PT_BR
       collation    PT_PT
   </charset>

   <charset WIN1250>
       intl_module    fbintl
       collation    WIN1250
       collation    PXW_CSY
       collation    PXW_HUN
       collation    PXW_HUNDC
   </charset>
      

Due nuovi set di caratteri aggiunti in Firebird 2 sono di particolare interesse per chi ha litigato in passato con i pasticci generati da UNICODE_FSS nelle versioni precedenti.

  isql -q -ch dos850
  SQL> create database 'test.fdb';
  SQL> create table t (c char(1) character set utf8);
  SQL> insert into t values ('a');
  SQL> insert into t values ('A');
  SQL> insert into t values ('á');
  SQL> insert into t values ('b');
  SQL> insert into t values ('B');
  SQL> select * from t order by c collate ucs_basic;

  C
  ======
  A
  B
  a
  b
  á

  SQL> select * from t order by c collate unicode;

  C
  ======
  a
  A
  á
  b
  B
        

La versione 2.1 aggiunge delle funzionalità relative a

Tutti i set di caratteri non grandi e basati su ASCII presenti in ICU possono essere usati da Firebird 2.1. Per ridurre la dimensione del kit in distribuzione, si è personalizzato ICU per includere solo i set di caratteri essenziali e quelli per i quali c'è stata una specifica richiesta.

Se il set di caratteri di cui si ha bisogno non è incluso, si possono sostituire le librerie ICU con altri moduli, reperibili al nostro sito o già installati nel sistema operativo.

<charset         NAME>
    intl_module     fbintl
    collation       NAME [REAL-NAME]
</charset>
          

<charset         GB>
    intl_module     fbintl
    collation       GB GB18030
</charset>
            

execute procedure sp_register_character_set ('GB', 4);
            

CREATE COLLATION <name>
    FOR <charset>
    [ FROM <base> | FROM EXTERNAL ('<name>') ]
    [ NO PAD | PAD SPACE ]
    [ CASE SENSITIVE | CASE INSENSITIVE ]
    [ ACCENT SENSITIVE | ACCENT INSENSITIVE ]
    [ '<specific-attributes>' ]
            

/* 1 */
CREATE COLLATION UNICODE_ENUS_CI
    FOR UTF8
    FROM UNICODE
    CASE INSENSITIVE
    'LOCALE=en_US';
/* 2 */
CREATE COLLATION NEW_COLLATION
    FOR WIN1252
    PAD SPACE;

/* NEW_COLLATION deve essere dichiarata nel file .conf
   bel direttorio $root/intl  */
          

Gli ordinamenti UNICODE (sia sensibili che insensibili alle maiuscole) possono essere applicati a tutti i set di caratteri presenti in fbintl. Essi sono già registrati in fbintl.conf, ma bisogna registrarli nel database con le associazioni ed attributi prescelti.

Convenzioni nel nome

Per convenzione il nome da usare è nella forma <nome set caratteri>_<ordinamento>. Ad esempio,

create collation win1252_unicode
  for win1252;

create collation win1252_unicode_ci
  for win1252
   from win1252_unicode
   case insensitive;
      

Se i meta-dati del tuo database sono stati creati con una codifica non ASCII, bisogna riparare il database per poter leggere i meta-dati correttamente dopo un aggiornamento alla versione 2.1.

[1] isql /percorso/al/tuo/database.fdb
[2] SQL> input '$fbroot$/misc/upgrade/metadata/metadata_charset_create.sql';
        

[1] isql /percorso/al/tuo/database.fdb
[2] SQL> select * from rdb$check_metadata;
        

[1] isql /percorso/al/tuo/database.fdb
[2] SQL> input '$fbroot$/misc/upgrade/metatdata/metadata_charset_create.sql';
[3] SQL> select * from rdb$fix_metadata('WIN1251');  -- sostituire WIN1251 col set di caratteri scelto
[4] SQL> commit;
        

[1] isql /percorso/al/tuo/database.fdb
[2] SQL> input '$fbroot$/misc/upgrade/metadata/metadata_charset_drop.sql';
        

Il punto chiave del sistema di monitoraggio è un'istantanea delle attività (activity snapshot). Essa rappresenta lo stato corrente del database, comprese una serie di informazioni sul DB stesso, sui collegamenti e gli utenti attivi, le transazioni, i comandi preparati ed in esecuzione, ed altro ancora.

Questa istantanea viene creata nel momento stesso in cui una qualsiasi delle tabelle di monitoraggio viene richiesta in una data transazione e viene conservata fino al termine della transazione, in modo tale che le interrogazioni multitabellari (esempio quelle master-slave) a tali tabelle possano riportare sempre una vista consistente dei dati.

In altre parole, le tabelle di monitoraggio si comportano sempre come in una transazione snapshot table stability («consistency»), anche se la transazione è partita con un livello di isolamento più basso.

Per rinfrescare l'istantanea (o snapshot) la transazione corrente dovrebbe essere terminata e le tabelle di monitoraggio vanno reinterrogate nel contesto di una nuova transazione.

La creazione di uno snapshot (istantanea) è normalmente un'operazione veloce, ma ci potrebbe essere un certo ritardo in caso di notevole carico di lavoro (specialmente nel Classic Server). Le linee guida per minimizzare l'impatto del monitoraggio in tali condizioni, vedere oltre nelle linee guida sulle prestazioni.

Per ricevere i dati di monitoraggio occorre essere connessi in modo valido ad un database. Le tabelle di monitoraggio danno informazioni solo sul database connesso. Se ci si connette a più database sullo stesso server, ognuno deve essere connesso e monitorato separatamente.

Le variabili di sistema CURRENT_CONNECTION e CURRENT_TRANSACTION possono essere utilizzate per filtrare i dati relativi rispettivamente alla attuale connessione o transazione del chiamante. Queste variabili corrispondono infatti alle colonne ID delle tabelle di monitoraggio appropriate.

Esempi

Per quanto spiegato finora, al fine di ottenere prove significative, è bene sperimentare su un database con più connessioni attive e collegandosi come SYSDBA o come proprietario del database.

Le query interminabili e lunghe possono essere bloccate e cancellate da una connessione separata.

Non c'è nessuna primitiva API dedicata a questa funzione. Sarà compito dell'amministratore del database (SYSDBA o il proprietario) utilizzare le informazioni provenienti dalle tabelle di monitoraggio e determinare un appropriato meccanismo per mettere in riga gli statement fuori controllo.

Esempio

Come esempio molto grezzo, col seguente comando si terminano tutti gli statement attualmente in esecuzione sul database tranne quelli che girano sulla connessione separata che viene usata dall'amministratore stesso che ha lanciato il comando:

delete from mon$statements
  where mon$attachment_id <> current_connection
    

Il monitoraggio è basato su due fondamenti: la memoria condivisa e le notifiche.

Il nuovo database per la sicurezza è stato rinominato security2.fdb. Internamente, la tabella di autenticazione degli utenti, dove sono memorizzati i nomi e le password degli utenti, è stata rinominata RDB$USERS. Non esiste più la tabella «users» ma una nuova vista su RDB$USERS che è nominata «USERS». Attraverso tale vista gli utenti possono cambiarsi le loro password.

Per dettagli sul nuovo database, vedere Nuovo database della sicurezza nella sezione sull'autenticazione più oltre in questo capitolo.

Per istruzioni sul come aggiornare dalla precedente versione del database della sicurezza, fare riferimento alla fine di questo capitolo alla sezione Gestione del nuovo database di sicurezza.

(V.2.1) A partire da Firebird 2.1, si può utilizzare il sistema di autenticazione degli utenti di Windows («Trusted User» security) per verificare le credenziali degli utenti Firebird su una piattaforma Windows. Il contesto degli utenti convalidati viene passato al server Firebird invece del nome utente e password e, se positivo, viene usato per determinare il nome utente Firebird.

Per dettagli vedere più avanti la sezione, Sicurezza con Windows Trusted Users.

Il sistema di criptazione/decriptazione delle password adesso usa un migliore algoritmo di calcolo.

Il SYSDBA rimane il proprietario del database della sicurezza. Tuttavia gli utenti possono modificarsi la loro propria password.

Anche il programma di utilità gsec ora usa le API di servizio. Il server rifiuta qualsiasi tipo di accesso al security2.fdb se non attraverso le API del gestore dei servizi (Services Manager).

I tentativi di accedere al server usando tecniche brutali sugli nominativi e le password sono rilevati e bloccati.

Il supporto di protezione contro gli attacchi brutali è stato incluso nelle funzioni di connessione sia delle API di Firebird sia delle API di servizio. Per altri dettagli vedere Protezione dagli attacchi brutali

Alcune note vulnerabilità nell'API sono state chiuse.

L'autenticazione in Firebird controlla su un database di sicurezza a livello di server per decidere se autorizzare una connessione ad un database o al server. Il database della sicurezza memorizza i nomi utente e le password di tutte le identità autorizzate.

Misure speciali sono state adottate per rendere completamente impossibili le connessioni remote al database della sicurezza. Non ci si deve sorprendere se qualche vecchio programma non riesce ad accedere direttamente: questo è voluto. Adesso si può accedere alle informazioni degli utenti solo attraverso le API di servizio e l'accesso interno ai servizi equivalente implementato ora nelle funzioni API isc_user_*.

Le attuali velocissime CPU e le connessioni WAN veloci rendono possibile tentare di attaccare brutalmente le password degli utenti di un server Firebird. Questo è pericolo specialmente per il Superserver che effettua, fin dalla versione 1.5, un'autenticazione dell'utente molto veloce. Il server Classic è più lento, poiché deve creare un nuovo processo per ogni connessione, collegarsi al database della sicurezza attraverso quella connessione e preparare una richiesta alla tabella RDB$USERS prima di poter validare login e password. Il Superserver bufferizza le connessioni e le richieste, permettendo una validazione dell'utente molto più veloce.

Data la lunghezza massima di 8 byte delle tradizionali password di Firebird, l'attacco brutale ha una ragionevole possibilità di successo per irrompere nell'installazione Firebird.

La versione 2.0 del Superserver ha una protezione attiva per rendere più difficili gli attacchi. Dopo alcuni tentativi di accesso falliti, l'utente e l'indirizzo IP vengono bloccati per alcuni secondi, impedendo per un breve periodo ogni tentativo di accesso successivo con quel nome utente OPPURE da quel particolare indirizzo IP.

Non sono richieste impostazioni o configurazioni per questa caratteristica. Viene automaticamente attivata appena parte il SuperServer Firebird 2.0.

Gli utenti Windows possono ricevere garanzie di accesso agli oggetti e ai ruoli del database allo stesso modo degli utenti Firebird standard, similmente a quanto è sempre stato disponibile per gli utenti dei database Firebird ospitati su Unix e Linux.

Se un amministratore locale o un membro del gruppo predefinito di Amministratori di Dominio si connette a Firebird utilizzando l'autenticazione trusted, viene connesso come SYSDBA.

Il nuovo parametro Authentication è stato aggiunto in firebird.conf per configurare il metodo si autenticazione in Windows. I possibili valori sono:

Nel caso in cui sia necessaria l'autenticazione trusted e c'è la possibilità di trovare impostate ISC_USER e ISC_PASSWORD, c'è un nuovo parametro in DPB che può essere aggiunto al DPB, isc_dpb_trusted_auth.

Molte delle utilità a linea di comando di Firebird supportano parametri attraverso lo switch -tru[sted] (la forma abbreviata è disponibile, secondo le regole usuali per abbreviare gli switch).

Esempio

C:\Pr~\bin>isql srv:db            -- entra usando l'autenticazione trusted
C:\Pr~\bin>set ISC_USER=utente1
C:\Pr~\bin>set ISC_PASSWORD=12345
C:\Pr~\bin>isql srv:db            -- entra usando 'utente1' specificato nell'ambiente
C:\Pr~\bin>isql -trust srv:db     -- entra usando l'autenticazione trusted
      

Richiesta CORE-1091

(V.2.1) Configurando il server con "DatabaseAccess = None", isc_service_query() riportava il percorso completo di nome file del database. Adesso è stato corretto per riportare il solo alias, un argomento in più a favore di rendere standard l'uso degli alias!

Richiesta CORE-1148

Questa era una vulnerabilità della sicurezza minore. Gli utenti normali adesso sono bloccati se cercano di accedere al log del server attraverso le API di servizio. Le richieste sono verificate esplicitamente al fine di assicurare che l'utente autenticato sia SYSDBA.

Per effettuare tale aggiornamento, seguire questa procedura:

Ora dovrebbe essere possibile collegarsi al server Firebird 2 utilizzando i vecchi login e password.

  RDB$PASSWD RDB$PASSWD,        

  RDB$PASSWD RDB$PASSWD NOT NULL,        

(V. 2.1) Un nuovo parametro è stato aggiunto a gbak, nbackup e isql per non eseguire Trigger a livello di database. Ciò è disponibile solo al proprietario del database e a SYSDBA:

  gbak -nodbtriggers
  isql -nodbtriggers
  nbackup -T
      

Le utilità a linea di comando che accettano il parametro -password sono vulnerabili alla cattura della password, specialmente quando sono lanciate da uno script. Un ulteriore passo nell'ostacolare tutto ciò nelle piattaforme POSIX, consiste nel mostrare nella lista dei processi l'argomento [PASSWORD] con un asterisco ( * ), mentre prima veniva visualizzato in chiaro.

(V.2.1) La nuova utilità fbsvcmgr permette un'interfaccia a linea di comando verso le API di servizio, permettendo l'accesso a tutti i servizi implementati in Firebird.

Sebbene ci siano in giro molti strumenti con interfaccia grafica per l'amministrazione dei database attraverso le API di servizio,questo nuovo strumento risolve agli amministratori il problema di accedere a server Unix remoti nelle grandi reti attraverso una connessione a linea di comando. Precedentemente per ottenere una cosa del genere era necessario ricorrere ad un programmatore.

isc_spb_dbname => dbname
isc_action_svc_backup => action_backup
isc_spb_sec_username => sec_username
isc_info_svc_get_env_lock => info_get_env_lock
          

Un sistema per effettuare copie di sicurezza veloci, on-line, a livello di pagina ed incrementale è stato implementato ex-novo.

Il sistema di backup è composto di due parti:

    nbackup <opzioni>
          

   -L <database>   Blocca il database per fare la copia
   -N <database>   Sblocca un database precedentemente bloccato
   -F <database>   Sistema il database dopo la copia
   -B <livello> <database> [<nomefile>]  Crea un backup incrementale
   -R <database> [<file0> [<file1>...]]   Restore di un backup incrementale
   -U <utente>     Nome dell'utente
   -P <password>   Password dell'utente
            

Un certo numero di miglioramenti sono stati apportati al programma di utilità gbak.

  -RECREATE_DATABASE [OVERWRITE]
        

  -R[EPLACE_DATABASE]
        

Sono stati aggiunti i seguenti switch alla linea di comando:

I seguenti comandi sono stati aggiunti o migliorati.

  SET HEADing [ON | OFF]
 

  SET TRANSACTION WAIT SNAPSHOT NO AUTO UNDO LOCK TIMEOUT 10
        

opt/firebird/bin] isql -?
Unknown switch: ?
usage:    isql [options] [<database>]
        -a(all)                 extract metadata incl. legacy non-SQL tables
        -b(ail)                 bail on errors (set bail on)
        -c(ache) <num>          number of cache buffers
        -ch(arset) <charset>    connection charset (set names)
        -d(atabase) <database>  database name to put in script creation
        -e(cho)                 echo commands (set echo on)
        -ex(tract)              extract metadata
        -i(nput) <file>         input file (set input)
        -m(erge)                merge standard error
        -m2                     merge diagnostic
        -n(oautocommit)         no autocommit DDL (set autoddl off)
        -now(arnings)           do not show warnings
        -o(utput) <file>        output file (set output)
        -pag(elength) <size>    page length
        -p(assword) <password>  connection password
        -q(uiet)                do not show the message "Use CONNECT..."
        -r(ole) <role>          role name
        -r2 <role>              role (uses quoted identifier)
        -sqldialect <dialect>   SQL dialect (set sql dialect)
        -t(erminator) <term>    command terminator (set term)
        -u(ser) <user>          user name
        -x                      extract metadata
        -z                      show program and server version
        

gsec adesso riporta un codice di errore quando non viene usato interattivamente. Zero indica successo; ogni altro valore indica problemi.

Le opzioni di gfix -shut[down] sono state estese per includere i due stati o modi extra per gestire lo shutdown.

Nuova sintassi

      gfix <comando> [<stato>] [<opzioni>]

  <comando> ::= {-shut | -online}
  <stato> ::= {normal | multi | single | full}
  <opzioni> ::= {-force <timeout> | -tran | -attach}
     

- stato «normal» = database online

- stato «multi» = modo shutdown multi-utenza (quello compatibile, permesse connessioni illimitate da SYSDBA/proprietario)

- stato «single» = shutdown in singola-utenza (solo una connessione permessa, usato dal processo di restore)

- stato «full» = shutdown completo o esclusivo (non sono permesse connessioni)

I modi possono essere modificati sequenzialmente secondo questo ordine:

Esempi