Cursori

Articolo
06/25/2013

Nei database relazionali le operazioni vengono eseguite su set di righe completi. Ad esempio, il set di righe restituito dall'istruzione SELECT include tutte le righe che soddisfano le condizioni specificate nella clausola WHERE dell'istruzione. Il set di righe completo restituito dall'istruzione è noto come set di risultati. Le applicazioni, soprattutto le applicazioni online interattive, non sono sempre in grado di gestire in modo efficiente un intero set di risultati come singola unità. In tali applicazioni deve essere pertanto disponibile un meccanismo per l'elaborazione di una riga singola o di un blocco di righe di dimensioni ridotte. I cursori sono un'estensione dei set di risultati che implementano appunto tale meccanismo.

I cursori estendono l'elaborazione dei risultati nel modo seguente:

Consentono il posizionamento su righe specifiche del set di risultati.
Recuperano una riga o un blocco di righe dalla posizione corrente del set di risultati.
Supportano la modifica dei dati delle righe in corrispondenza della posizione corrente del set di risultati.
Supportano livelli diversi di visibilità per le modifiche apportate da altri utenti ai dati del database inclusi nel set di risultati.
Consentono alle istruzioni Transact-SQL incluse in script, stored procedure e trigger di accedere ai dati di un set di risultati.

Concetti

Implementazione dei cursori
SQL Server supporta l'implementazione di tre tipi di cursori.
- Cursori Transact-SQL
  Sono basati sulla sintassi DECLARE CURSOR e sono principalmente utilizzati in trigger, stored procedure e script Transact-SQL. I cursori Transact-SQL vengono implementati nel server e gestiti dalle funzioni Transact-SQL inviate dal client al server. Possono essere inoltre inclusi in batch, stored procedure o trigger.
- Cursori API (Application Programming Interface) del server
  Supportano le funzioni dei cursori API in OLE DB e ODBC. Questi cursori sono implementati nel server. Ogni volta che un'applicazione client chiama una funzione per un cursore API, il provider OLE DB o il driver ODBC di Native Client SQL Server trasmette al server la richiesta di eseguire un'azione sul cursore API del server.
- Cursori client
  Sono implementati internamente dal driver ODBC di Native Client SQL Server e dalla DLL che implementa l'API ADO. I cursori client vengono implementati mediante la memorizzazione nella cache del client di tutte le righe del set di risultati. Ogni volta che un'applicazione client chiama una funzione per un cursore API, il driver ODBC di Native Client SQL Server o la DLL ADO esegue l'operazione del cursore nelle righe del set di risultati memorizzate nella cache del client.
Tipo di cursori
- Forward-only
  I cursori forward-only non supportano lo scorrimento, ma solo le operazioni di recupero seriale delle righe dall'inizio alla fine del cursore. Le righe vengono prelevate dal database solo quando si esegue l'operazione di recupero. Gli effetti delle istruzioni INSERT, UPDATE e DELETE eseguite dall'utente corrente o da altri utenti che coinvolgono le righe del set di risultati sono visibili nel momento in cui le righe vengono recuperate dal cursore.
  
  Poiché non è supportato lo scorrimento a ritroso del cursore, la maggior parte delle modifiche apportate alle righe nel database in seguito al recupero non sono visibili tramite il cursore. Nei casi in cui un valore utilizzato per determinare la posizione della riga all'interno del set di risultati viene modificato, ad esempio tramite l'aggiornamento di una colonna coperta da un indice cluster, il valore modificato sarà visibile tramite il cursore.
  
  Anche se i modelli di cursore API del database considerano un cursore forward-only un tipo distinto di cursore, SQL Server non fa questa distinzione. SQL Server considera il forward-only e lo scorrimento come opzioni da applicare ai cursori statici, gestiti da keyset e dinamici. I cursori Transact-SQLsupportano i cursori dinamici, i cursori gestiti da keyset e i cursori statici forward-only. In base ai modelli di cursore dell'API di database i cursori dinamici, gestiti da keyset o statici sono sempre scorrevoli. I cursori API del database con una proprietà o un attributo impostato su forward-only vengono implementati in SQL Server come cursori forward-only dinamici.
- Statico
  Il set di risultati completo di un cursore statico viene compilato nel database tempdb all'apertura del cursore. Un cursore statico visualizza sempre il set di risultati così come è visualizzato all'apertura del cursore. I cursori statici rilevano poche modifiche o addirittura nessuna, ma utilizzano un numero relativamente ridotto di risorse per lo scorrimento.
  
  Nel cursore non vengono riportate né le modifiche al database che hanno effetto sull'appartenenza del set di risultati, né le modifiche apportate ai valori inclusi nelle colonne delle righe del set di risultati. Un cursore statico non visualizza le nuove righe inserite nel database dopo l'apertura del cursore, anche se tali righe soddisfano le condizioni di ricerca dell'istruzione SELECT del cursore. Non visualizza inoltre gli aggiornamenti eseguiti da altri utenti nelle righe del set di risultati. Un cursore statico riflette invece le operazioni di eliminazione di righe dal database dopo l'apertura del cursore. Il risultato delle operazioni UPDATE, INSERT e DELETE non viene mai riportato nel cursore statico, né le modifiche eseguite sulla stessa connessione in cui è stato aperto il cursore (a meno che il cursore non venga chiuso e riaperto).
  
  I cursori statici di SQL Server sono sempre di sola lettura.
  
  Poiché il set di risultati di un cursore statico viene archiviato in una tabella di lavoro in tempdb, la lunghezza delle righe non può essere maggiore della lunghezza di riga massima consentita per le tabelle di SQL Server.
  
  In Transact-SQL i cursori statici sono definiti cursori di tipo insensitive. Alcune API di database li identificano come cursori snapshot.
- Keyset
  L'appartenenza e l'ordine delle righe di un cursore gestito da keyset vengono fissati al momento dell'apertura del cursore. I cursori gestiti da keyset vengono controllati da un set di identificatori univoci, ovvero chiavi, noti come keyset. Le chiavi sono costituite da un set di colonne che identificano in modo univoco le righe del set di risultati. Il keyset corrisponde al set di valori chiave di tutte le righe risultanti dall'istruzione SELECT al momento dell'apertura del cursore. Il keyset di un cursore gestito da keyset viene compilato nel database tempdb all'apertura del cursore.
- Dinamico
  I cursori dinamici sono l'opposto dei cursori statici. Quando si scorre un cursore dinamico vengono visualizzate tutte le modifiche apportate alle righe del set di risultati corrispondente. I valori di dati, l'ordine e l'appartenenza delle righe del set di risultati possono variare a ogni operazione di recupero. I risultati delle istruzioni UPDATE, INSERT e DELETE eseguite da tutti gli utenti sono visibili nel cursore. Gli aggiornamenti sono visibili immediatamente se eseguiti nel cursore tramite una funzione API quale SQLSetPos o la clausola WHERE CURRENT OF Transact-SQL. Gli aggiornamenti eseguiti all'esterno del cursore risultano visibili solo dopo l'operazione di commit, a meno che il livello di isolamento della transazione non sia impostato su read uncommitted.

Richiesta di cursori

SQL Server supporta due metodi per richiedere un cursore:

Transact-SQL

Il linguaggio Transact-SQL supporta una sintassi per l'utilizzo dei cursori creati in base alla sintassi del cursore ISO.
Funzioni per i cursori delle API di database

SQL Server supporta la funzionalità per i cursori delle API di database seguenti:
- ADO (Microsoft ActiveX Data Object)
- OLE DB
- ODBC (Open Database Connectivity)

Questi due metodi non devono essere implementati entrambi nella stessa applicazione. In un'applicazione in cui le funzionalità del cursore sono state implementate tramite le API, non è consentito richiedere un cursore Transact-SQL tramite l'istruzione Transact-SQL DECLARE CURSOR. L'istruzione DECLARE CURSOR può essere eseguita solo dopo il ripristino di tutti i valori predefiniti degli attributi dei cursori API.

Se non è stato richiesto né un cursore Transact-SQL, né un cursore API, per impostazione predefinita SQL Server restituisce all'applicazione un set di risultati completo, ovvero un set di risultati predefinito.

Processo del cursore

I cursori Transact-SQL e i cursori API prevedono una sintassi diversa, ma per tutti i cursori di SQL Server viene utilizzata la seguente procedura generale:

Associare un cursore al set di risultati di un'istruzione Transact-SQL e definirne le caratteristiche, ad esempio se le righe del cursore sono aggiornabili.
Eseguire l'istruzione Transact-SQL per popolare il cursore.
Recuperare le righe del cursore che si desidera visualizzare. L'operazione che consente di ottenere una riga o un blocco di righe da un cursore è definita operazione di recupero. L'esecuzione di una serie di operazioni di recupero in avanti o a ritroso è definita scorrimento.
Facoltativamente, eseguire operazioni di modifica (aggiornamento o eliminazione) sulla riga che si trova nella posizione corrente del cursore.
Chiudere il cursore.