Tipi di cursori
Microsoft I cursori di SQL Server Compact 3.5 (SQL Server Compact 3.5) sono simili ai cursori utilizzati in SQL Server, con alcune differenze che verranno illustrate in questa sezione. Per una descrizione completa dei cursori di database, vedere la documentazione in linea di SQL Server.
SQL Server Compact 3.5 supporta i tipi di cursori seguenti:
- Per tabelle di base
- Statici
- Forward-only
- Forward-only/di sola lettura
- Gestiti da keyset
Cursori per tabelle di base
I cursori per tabelle di base costituiscono il più basso livello di cursore disponibile. Questi cursori interagiscono direttamente con il motore di archiviazione e sono i più veloci tra tutti i tipi di cursori supportati. I cursori per tabelle di base possono scorrere avanti o indietro con un costo minimo e possono essere aggiornati.
È inoltre possibile aprire un cursore direttamente su un indice. Sono supportati indici per l'ordinamento delle righe di una tabella, per la ricerca di determinati valori e per la restrizione delle righe in base a un intervallo di valori all'interno di un indice.
I cursori per tabelle di base sono caratterizzati da un'appartenenza dinamica. Di conseguenza, due cursori aperti sulla stessa tabella possono rilevare immediatamente gli inserimenti, le eliminazioni e le modifiche ai dati, a condizione che entrambi siano inclusi nello stesso ambito di transazione. Poiché i cursori per tabelle di base possono essere aggiornati, un client può utilizzare questo tipo di cursore per apportare modifiche ai dati sottostanti.
I cursori per tabelle di base non possono rappresentare il risultato di una query. I risultati delle query, ad esempio SELECT * FROM tablename, non vengono infatti restituiti tramite un cursore per tabelle di base. Viene invece utilizzato uno dei cursori per risultati di query supportati.
Di seguito viene illustrato un esempio di come ottenere un cursore per tabelle di base mediante ADO .NET:
//Base Table Cursor
cmd.CommandText = "tablename";
cmd.CommandType = CommandType.TableDirect;
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Scrollable | ResultSetOptions.Updatable);
Di seguito viene illustrato un esempio di come ottenere un cursore per indici mediante ADO .NET:
cmd.CommandText = "tablename";
cmd.IndexName = "indexname";
cmd.CommandType = CommandType.TableDirect;
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Scrollable | ResultSetOptions.Updatable);
Cursori statici
Un cursore statico, denominato cursore scrollable query nelle versioni precedenti di SQL Server Compact 3.5, crea e archivia una copia completa del set dei risultati. L'unica eccezione è rappresentata dai dati con valori di tipo Long che vengono recuperati solo se un utente li richiede in modo esplicito. Questo set dei risultati viene quindi riempito solo in base alle esigenze. Ciò costituisce una differenza rispetto a SQL Server, in cui il set dei risultati viene popolato alla creazione del cursore. I cursori statici supportano lo scorrimento avanti e indietro, ma non supportano aggiornamenti. I cursori statici non rilevano le modifiche esterne ai dati di tipo insensitive. I risultati delle query vengono memorizzati nella cache per il ciclo di vita del cursore. Nonostante siano più funzionali rispetto ai cursori forward-only, i cursori statici sono più lenti e utilizzano una maggiore quantità di memoria. È consigliabile considerare i cursori statici solo se è necessario lo scorrimento e non è appropriato un cursore keyset.
Di seguito viene illustrato un esempio di come ottenere un cursore statico mediante ADO.NET:
cmd.CommandText = "Select * from tablename";
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Scrollable | ResultSetOptions.Insensitive);
Cursori forward-only
Il cursore forward-only è il cursore aggiornabile più veloce, ma non supporta lo scorrimento. Supporta solo il recupero seriale delle righe dall'inizio alla fine del cursore. Le righe vengono recuperate dal database soltanto con questa operazione. Gli effetti di tutte le istruzioni INSERT, UPDATE e DELETE che vengono eseguite dall'utente corrente o con commit di altri utenti e influiscono sulle righe nel set dei risultati sono visibili con il recupero delle righe da parte del cursore. Poiché il cursore non supporta lo scorrimento indietro, le modifiche apportate alle righe nel database dopo il recupero della riga non sono visibili mediante il cursore.
I cursori forward-only e forward-only/di sola lettura sono i cursori basati su query più veloci ed è quindi consigliabile utilizzarli in scenari in cui la velocità e la quantità di memoria occupata rivestono la massima importanza.
Di seguito viene illustrato un esempio di come ottenere un cursore forward-only mediante ADO .NET:
cmd.CommandText = "Select * from tablename";
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Updatable);
Cursori forward-only/di sola lettura
I cursori forward-only/di sola lettura, denominati cursori forward-only nelle versioni precedenti di SQL Server Compact 3.5, sono i cursori più veloci, ma non possono essere aggiornati.
Di seguito viene illustrato un esempio di come ottenere un cursore forward-only/di sola lettura mediante ADO.NET:
cmd.CommandText = "Select * from tablename";
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.None);
Nota Non è possibile creare cursori di sola lettura per query che restituiscono colonne di sola lettura, poiché internamente tutti i cursori di SQL Server Compact 3.5 sono aggiornabili. SQL Server Compact 3.5 non può aggiornare le colonne di sola lettura restituite in SqlCeResultSet. Si verifica pertanto l'errore "Impossibile generare un cursore aggiornabile per la query perché non è presente una colonna aggiornabile".
Cursori gestiti da keyset
Il cursore gestito da keyset di SQL Server Compact 3.5 è un cursore scorrevole e aggiornabile, controllato da un insieme di identificatori fisici denominato keyset. Il keyset è basato su tutte le righe qualificate per l'istruzione SELECT al momento dell'apertura del cursore. Il keyset viene creato in una tabella temporanea all'apertura del cursore. Con un cursore gestito da keyset, l'appartenenza viene determinata al momento dell'esecuzione della query.
I cursori gestiti da keyset di SQL Server Compact 3.5 differiscono leggermente rispetto a quelli di SQL Server. In SQL Server il cursore gestito da keyset utilizza un insieme di identificatori univoci come chiavi del keyset, mentre in SQL Server Compact 3.5 le chiavi sono segnalibri che indicano la posizione in cui i valori sono archiviati logicamente all'interno di una tabella. Non costituiscono identificatori univoci.
Sebbene sensibile a diverse modifiche, un cursore gestito da keyset presenta una sensibilità inferiore rispetto ad altri cursori. Un inserimento all'esterno del cursore, ad esempio, non viene rilevato, nonostante gli inserimenti all'interno del cursore vengano rilevati alla fine. In questo caso, è consigliabile chiudere e riaprire il cursore oppure utilizzare un cursore forward-only.
Poiché SQL Server Compact 3.5 utilizza segnalibri per definire un keyset, tutte le modifiche apportate ai valori di dati per le righe incluse nel keyset sono visibili mediante il cursore. Ciò si verifica sia per le modifiche apportate all'interno che per quelle apportate all'esterno del cursore.
In seguito a qualsiasi eliminazione in un cursore keyset, sia all'interno che all'esterno del cursore, in caso di tentativo di recupero la riga verrà segnalata come eliminata.
Di seguito viene illustrato un esempio di come ottenere un cursore gestito da keyset mediante ADO .NET:
cmd.CommandText = "Select * from tablename";
SqlCeResultSet rs = cmd.ExecuteResultSet(ResultSetOptions.Scrollable | ResultSetOptions.Updatable);
Utilizzo di join
Se la query utilizzata per aprire un cursore gestito da keyset include colonne unite in join, tali colonne non sono aggiornabili. L'utente può inserire nuovi valori nelle colonne, ma gli aggiornamenti non sono supportati.
Se il keyset viene utilizzato per popolare un controllo aggiornabile dall'utente, come un oggetto DataGrid, in caso di tentativo di aggiornamento dei valori nel controllo da parte degli utenti l'aggiornamento avrà esito negativo. Se si sviluppa un'applicazione che utilizza un DataGrid per visualizzare dati di colonne unite in join, assicurarsi di impostare le colonne unite in join nel DataGrid come di sola lettura.
Vedere anche
Concetti
Cursori (SQL Server Compact)
Scelta del tipo di cursore
Cursori e blocco
Conversioni implicite dei cursori
Aggiornamento di cursori gestiti da keyset