Query distribuite di Microsoft SQL Server: connettività OLE DB

Questo articolo descrive il modo in cui il processore di query di Microsoft SQL Server interagisce con un provider OLE DB per abilitare query distribuite ed eterogenee. È destinato principalmente agli sviluppatori di provider OLE DB e presuppone una conoscenza approfondita della specifica OLE DB. L'articolo è incentrato sull'interfaccia OLE DB tra il processore di query di SQL Server e il provider OLE DB e non sulla funzionalità delle query distribuite. Per una descrizione completa della funzionalità di query distribuita, vedere Server collegati (motore di database).

Panoramica e terminologia

In Microsoft SQL Server le query distribuite consentono agli utenti SQL Server di accedere ai dati all'esterno di un server basato su SQL Server, all'interno di altri server che eseguono SQL Server o di altre origini dati che espongono un'interfaccia OLE DB. OLE DB consente di accedere in modo uniforme ai dati tabulari da origini dati eterogenee.

Ai fini di questo articolo, una query distribuita è costituita da un'istruzione SELECTINSERT, UPDATE o DELETE che fa riferimento a tabelle e set di righe da una o più origini dati OLE DB esterne.

Una tabella remota è una tabella archiviata in un'origine dati OLE DB ed esterna al server che esegue SQL Server in cui è in esecuzione la query. Una query distribuita accede a una o più tabelle remote.

Categorie di provider OLE DB

L'elenco seguente è una categorizzazione dei provider OLE DB in base alle relative funzionalità dal punto di vista delle query distribuite di SQL Server. Come definito, questi non si escludono a vicenda; un determinato provider può appartenere a più di una delle categorie seguenti:

Provider di comandi SQL
Provider di indici
Provider di tabelle semplici
Provider di comandi non SQL

Provider di comandi SQL

I provider che supportano l'oggetto Command con un dialetto standard SQL riconosciuto da SQL Server appartengono a questa categoria. I requisiti specifici di un provider OLE DB per essere considerato da SQL Server come provider di comandi SQL sono i seguenti:

Il provider deve supportare l'oggetto Command e tutte le relative interfacce OLE DB obbligatorie: ICommand, ICommandText, IColumnsInfo, ICommandProperties e IAccessor.
Il dialetto SQL supportato dal provider deve essere almeno SQL Subminimum. Il dialetto deve essere indicato dal provider tramite la proprietà DBPROP_SQLSUPPORT.

Esempi di provider di comandi SQL sono il provider Microsoft OLE DB per SQL Server e il provider Microsoft OLE DB per ODBC.

Provider di indici

I provider di indici sono provider che supportano ed espongono gli indici in base a OLE DB e consentono la ricerca basata sull'indice delle tabelle di base. I requisiti specifici di un provider OLE DB per essere considerato da SQL Server come provider di indici sono i seguenti:

Il provider deve supportare l'interfaccia IDBSchemaRowset con i set di righe dello TABLESschema e COLUMNSINDEXES .
Il provider deve supportare l'apertura di un set di righe in un indice tramite IOpenRowset specificando il nome dell'indice e il nome della tabella di base corrispondente.
L'oggetto Index deve supportare tutte le relative interfacce obbligatorie: IRowset, IRowsetIndex, IAccessor, IColumnsInfo, IRowsetInfo e IConvertTypes.
I set di righe aperti nella tabella di base indicizzata (tramite IOpenRowset) devono supportare l'interfaccia IRowsetLocate per il posizionamento in una riga in base a un segnalibro.

Se il provider OLE DB soddisfa i requisiti precedenti, gli utenti possono impostare l'opzione Index As Access Path del provider per consentire a SQL Server di usare gli indici del provider per valutare le query. Per impostazione predefinita, SQL Server non tenta di usare gli indici del provider, a meno che non sia impostata questa opzione.

Nota

SQL Server supporta diverse opzioni che influenzano il modo in cui SQL Server accede a un provider OLE DB. Per impostare queste opzioni è possibile usare la finestra di dialogo Linked Server Properties in SQL Server Enterprise Manager.

Provider di tabelle semplici

Questi provider consentono l'apertura di un set di righe su una tabella di base tramite l'interfaccia IOpenRowset. Tali provider non sono né provider di comandi SQL né provider di indici; sono invece la classe più semplice di provider con cui le query distribuite di SQL Server possono funzionare.

In questi provider SQL Server può eseguire solo scansioni di tabella durante la valutazione delle query distribuite.

Provider di comandi non SQL

I provider che supportano l'oggetto Command e le relative interfacce obbligatorie, ma non supportano un dialetto standard SQL riconosciuto da SQL Server, rientrano in questa categoria.

Il provider Microsoft OLE DB per il servizio di indicizzazione e il provider Microsoft OLE DB per il servizio Microsoft Active Directory sono due esempi di provider di comandi non SQL.

Transact-SQL subset

Ognuna delle seguenti classi di istruzioni Transact-SQL è supportata per le query distribuite se il provider supporta le interfacce OLE DB obbligatorie.

Tutte le SELECT istruzioni sono consentite ad eccezione SELECT INTO delle istruzioni con una tabella remota come tabella di destinazione.
Le istruzioni INSERT sono consentite nelle tabelle remote se il provider supporta le interfacce necessarie per l'inserimento. Per altre informazioni sui requisiti OLE DB per INSERT, vedere istruzione INSERT più avanti in questo articolo.
UPDATE Le istruzioni e DELETE sono consentite su tabelle remote se il provider soddisfa i requisiti dell'interfaccia OLE DB nella tabella specificata. Per i requisiti e le condizioni dell'interfaccia OLE DB in cui è possibile aggiornare o eliminare una tabella remota, vedere istruzioni UPDATE e DELETE più avanti in questo articolo.

Supporto cursore

I cursori snapshot e keyset sono supportati nelle query distribuite se il provider supporta la funzionalità OLE DB necessaria. I cursori dinamici non sono supportati per le query distribuite. Una richiesta dell'utente per un cursore dinamico in una query distribuita viene declassata a un cursore keyset.

I cursori snapshot vengono popolati in fase di apertura del cursore e il set di risultati rimane invariato; gli aggiornamenti, gli inserimenti e le eliminazioni nelle tabelle sottostanti non vengono riflessi nel cursore.

I cursori keyset vengono popolati al momento dell'apertura del cursore e il set di risultati rimane invariato per tutta la durata del cursore. Tuttavia, gli aggiornamenti e le eliminazioni nelle tabelle sottostanti sono visibili nel cursore mentre vengono visitate le righe. Gli inserimenti nelle tabelle sottostanti che potrebbero influire sull'appartenenza al cursore non sono visibili.

Una tabella remota può essere aggiornata o eliminata tramite un cursore definito in una query distribuita e fa riferimento alla tabella remota se il provider soddisfa le condizioni per gli aggiornamenti e le eliminazioni nella tabella remota, UPDATE ad esempio tabella o DELETE <remote-table> WHERE CURRENT OF <cursor-name>. Per altre informazioni, vedere istruzioni UPDATE e DELETE più avanti in questo articolo.

Requisiti di supporto del cursore keyset

Un cursore keyset è supportato in una query distribuita se vengono soddisfatti tutti i requisiti della sintassi Transact-SQL e si verifica una delle condizioni seguenti:

Il provider OLE DB supporta i segnalibri riutilizzabili in tutte le tabelle remote della query. I segnalibri riutilizzabili possono essere consumati da un set di righe su una tabella e utilizzati su un set di righe diverso della stessa tabella. Il supporto per i segnalibri riutilizzabili viene indicato tramite il TABLES_INFO set di righe dello schema di IDBSchemaRowset impostando la BOOKMARK_DURABILITY colonna su BMK_DURABILITY_INTRANSACTION o una durabilità superiore.
Tutte le tabelle remote espongono una chiave univoca tramite il set di righe dell'interfaccia INDEXESIDBSchemaRowset . Deve essere presente una voce di indice con la UNIQUE colonna impostata su VARIANT_TRUE.

I cursori keyset non sono supportati per le query distribuite che coinvolgono la funzione OpenQuery .

Requisiti del cursore keyset aggiornabile

Una tabella remota può essere aggiornata o eliminata tramite un cursore keyset definito in una query distribuita, ad esempio UPDATE o DELETE <remote-table> WHERE CURRENT OF <cursor-name>. I cursori aggiornabili sono utilizzabili nelle query distribuite se vengono soddisfatti i requisiti seguenti:

I cursori aggiornabili sono consentiti se il provider soddisfa anche le condizioni per gli aggiornamenti e le eliminazioni nella tabella remota. Per altre informazioni, vedere istruzioni UPDATE e DELETE più avanti in questo articolo.
Tutte le operazioni dei cursori keyset aggiornabili devono essere incluse in una transazione definita dall'utente con un livello di isolamento di lettura ripetibile o un livello di isolamento superiore. Il provider deve anche supportare le transazioni distribuite con l'interfaccia ITransactionJoin.

Fasi di interazione del provider OLE DB

Sei operazioni sono comuni a tutti gli scenari di esecuzione di query distribuite:

Le operazioni di connessione e recupero delle proprietà indicano la modalità di connessione di SQL Server a un provider OLE DB e le proprietà del provider usate.
Le operazioni di risoluzione dei nomi di tabella e recupero dei metadati indicano il modo in cui SQL Server risolve il nome della tabella remota (specificato in uno dei due modi: un nome basato su server collegato o un nome ad hoc) nell'oggetto dati appropriato nel provider. Sono inclusi anche i metadati della tabella recuperati da SQL Server dal provider per compilare e ottimizzare una query distribuita.
Le operazioni di gestione transazioni specificano tutte le interazioni correlate alla transazione con il provider OLE DB.
Le operazioni di gestione dei tipi di dati indicano il modo in cui SQL Server gestisce i tipi di dati OLE DB quando utilizza o esporta dati in un provider OLE DB durante l'elaborazione di una query distribuita.
Le operazioni di gestione degli errori indicano il modo in cui SQL Server usa le informazioni estese sugli errori provenienti dal provider.
Le operazioni di sicurezza specificano il modo in cui la sicurezza di SQL Server interagisce con la sicurezza del provider.

Definizione della connessione e recupero delle proprietà

SQL Server supporta due convenzioni di denominazione degli oggetti dati remoti: nomi in quattro parti basati su server collegati e nomi ad hoc con la funzione OPENROWSET.

Nomi basati su server collegati

Un server collegato funge da astrazione per un'origine dati OLE DB. Un nome basato su server collegato è un nome in quattro parti nel formato <linked-server>.<catalog>. <schema>.<object>, dove <linked-server> è il nome del server collegato. SQL Server interpreta <linked-server> per derivare il provider OLE DB e gli attributi di connessione che identificano l'origine dati per il provider. Le altre tre parti del nome vengono interpretate dall'origine dati OLE DB per identificare la tabella remota specifica. :::

Nomi ad hoc

Un nome ad hoc è un nome basato sulla funzione OPENROWSET o OPENDATASOURCE. Include tutte le informazioni di connessione, cioè il provider OLE DB da usare, gli attributi necessari per identificare l'origine dati, l'ID utente e la password, ogni volta che la tabella remota viene fatta riferimento in una query distribuita.

L'uso di nomi ad hoc non è consentito per impostazione predefinita, ad eccezione dei membri del ruolo sysadmin. Per usare nomi ad hoc in un provider OLE DB, l'opzione del provider DisallowAdhocAccess deve essere impostata su 0.

Se viene usato un nome di server collegato, SQL Server estrae dalla definizione del server collegato il nome del provider OLE DB e le proprietà di inizializzazione per il provider. Se viene usato un nome ad hoc, SQL Server estrae le stesse informazioni dagli argomenti della funzione OPENROWSET.

Per istruzioni dettagliate sulla configurazione di un server collegato usando un nome in quattro parti e una sintassi basata su nomi ad hoc, vedere Creare server collegati (motore di database di SQL Server).

Connettersi a un provider OLE DB

Questi sono i passaggi di alto livello che SQL Server esegue quando si connette a un provider OLE DB:

SQL Server crea un oggetto di origine dati.

SQL Server utilizza ProgID del provider per istanziarne l'oggetto di origine dati (DSO). ProgID è specificato come parametro provider_name di una configurazione del server collegato o come primo argomento della funzione OPENROWSET nel caso di un nome ad hoc.

SQL Server crea un'istanza del Data Source Object (DSO) del provider attraverso l'interfaccia del componente del servizio OLE DB IDataInitialize. Ciò consente allo strumento di gestione dei componenti dei servizi di aggregare i servizi, ad esempio lo scorrimento e il supporto aggiornamenti, al di sopra della funzionalità nativa del provider. Inoltre, la creazione di un'istanza del provider tramite IDataInitialize consente al componente del servizio OLE DB di aggiungere a un pool le connessioni al provider riducendo il sovraccarico di connessione e inizializzazione.

Un provider specificato può essere configurato per essere istanziato nello stesso processo di SQL Server o in un processo separato. La creazione di un'istanza in un processo separato protegge il processo di SQL Server dagli errori nel provider. Allo stesso tempo, si verifica un sovraccarico delle prestazioni associato al marshalling delle chiamate OLE DB out-of-process da SQL Server. È possibile configurare un provider affinché venga istanziato "in-process" (internamente) o "out-of-process" (esternamente) impostando l'opzione del provider Allow In Process. Per altre informazioni, vedere l'impostazione delle opzioni del provider.

Per altre informazioni sui componenti del servizio OLE DB e sul pool di sessioni, consultare la documentazione OLE DB per i requisiti del provider.
L'origine dati viene inizializzata.

Dopo aver creato il DSO, l'interfaccia IDBProperties imposta la DBPROP_INIT_TIMEOUT proprietà di inizializzazione se l'opzione remote login timeout di configurazione del server è maggiore di 0. Si tratta di una proprietà obbligatoria.

Queste proprietà vengono impostate se sono specificate o implicite nella definizione del server collegato o nel secondo argomento della OPENROWSET funzione:
- DBPROP_INIT_PROVIDERSTRING
- DBPROP_INIT_DATASOURCE
- DBPROP_INIT_LOCATION
- DBPROP_INIT_CATALOG
- DBPROP_AUTH_USERID
- DBPROP_AUTH_PASSWORD
Una volta impostate queste proprietà, viene chiamato IDBInitialize::Initialize per inizializzare il Data Source Object (DSO) con le proprietà specificate.

SQL Server raccoglie le informazioni specifiche del provider.

SQL Server raccoglie diverse proprietà del provider che vengono usate nella valutazione delle query distribuite. Queste proprietà vengono recuperate tramite una chiamata a IDBProperties::GetProperties. Tutte queste proprietà sono facoltative. Tuttavia, il supporto di tutte le proprietà rilevanti consente a SQL Server di sfruttare al meglio le funzionalità del provider. Ad esempio, DBPROP_SQLSUPPORT è necessaria per determinare se SQL Server può inviare query al provider. Se questa proprietà non è supportata, SQL Server non usa il provider remoto come provider di comandi SQL anche se è uno. Nella tabella seguente la colonna Valore predefinito indica il valore assunto da SQL Server se il provider non supporta la proprietà .

Proprietà	Valore predefinito	Utilizzo
`DBPROP_DBMSNAME`	Nessuno	Usata per i messaggi di errore.
`DBPROP_DBMSVER`	Nessuno	Usata per i messaggi di errore.
`DBPROP_PROVIDERNAME`	Nessuno	Usata per i messaggi di errore.
`DBPROP_PROVIDEROLEDBVER1`	1,5	Usata per determinare la disponibilità delle funzionalità 2.0.
`DBPROP_CONCATNULLBEHAVIOR`	Nessuno	Usata per determinare se il comportamento di concatenazione `NULL` del provider corrisponde a quello di SQL Server.
`DBPROP_NULLCOLLATION`	Nessuno	Consente l'utilizzo dell'ordinamento/indice solo se `NULLCOLLATION` corrisponde al comportamento delle regole di confronto Null dell'istanza di SQL Server.
`DBPROP_OLEOBJECTS`	Nessuno	Determina se il provider supporta interfacce di archiviazione strutturate per colonne di oggetti dati di grandi dimensioni.
`DBPROP_STRUCTUREDSTORAGE`	Nessuno	Determina le interfacce di archiviazione strutturate supportate per i tipi di oggetti di grandi dimensioni (tra `ILockBytes`, `Istream`e `ISequentialStream`).
`DBPROP_MULTIPLESTORAGEOBJECTS`	Falso	Determina se è possibile aprire più di una colonna di oggetti di grandi dimensioni nello stesso momento.
`DBPROP_SQLSUPPORT`	Nessuno	Determina se le query SQL possono essere inviate al provider.
`DBPROP_CATALOGLOCATION`	`DBPROPVAL_CL_START`	Utilizzata per costruire nomi di tabelle multipartite.
`SQLPROP_DYNAMICSQL`	Falso	Proprietà specifica di SQL Server: se restituisce `VARIANT_TRUE`, indica che i marcatori di parametro `?` sono supportati per l'esecuzione di query con parametri.
`SQLPROP_NESTEDQUERIES`	Falso	Proprietà specifica di SQL Server: se restituisce `VARIANT_TRUE`, indica che il provider supporta le istruzioni `SELECT` nidificate nella clausola `FROM`.
`SQLPROP_GROUPBY`	Falso	Proprietà specifica di SQL Server: se restituisce `VARIANT_TRUE`, indica che il provider supporta `GROUP BY` la clausola nell'istruzione `SELECT` come specificato dallo standard SQL-92.
`SQLPROP_DATELITERALS`	Falso	Proprietà specifica di SQL Server: se restituisce `VARIANT_TRUE`, indica che il provider supporta i valori letterali datetime in base alla sintassi Transact-SQL di SQL Server.
`SQLPROP_ANSILIKE`	Falso	Proprietà specifica di SQL Server: Questa proprietà interessa ai provider che supportano il livello SQL-Minimum e supporta l'operatore `LIKE` secondo il livello di ingresso SQL-92 ('%' e '_' come caratteri jolly).
`SQLPROP_SUBQUERIES`	Falso	Proprietà SQL Server: questa proprietà è adatta ai provider che supportano il livello SQL-Minimum. La proprietà indica che il provider supporta le sottoquery come specificato dal livello di ingresso del SQL-92. Sono incluse le sottoquery nell'elenco `SELECT` e nella clausola `WHERE` con supporto per le sottoquery correlate e gli operatori `IN`, `EXISTS`, `ALL` e `ANY`.
`SQLPROP_INNERJOIN`	Falso	Proprietà specifica di SQL Server: questa proprietà è adatta ai provider che supportano il livello SQL-Minimum. Questa proprietà indica il supporto per i join con più tabelle nella clausola `FROM`.

I tre valori letterali seguenti vengono recuperati da IDBInfo::GetLiteralInfo: DBLITERAL_CATALOG_SEPARATOR, DBLITERAL_SCHEMA_SEPARATOR (per costruire un nome di oggetto completo in base alle parti del catalogo, dello schema e del nome dell'oggetto) e DBLITERAL_QUOTE (per citare i nomi degli identificatori in una query SQL inviata al provider).

Se il provider non supporta i valori letterali separatori, SQL Server usa un punto (.) come carattere separatore predefinito. Se il provider supporta solo il carattere separatore del catalogo e non supporta il carattere separatore dello schema, SQL Server usa il carattere separatore del catalogo anche come carattere separatore dello schema. Se il provider non supporta DBLITERAL_QUOTE, SQL Server usa una virgoletta singola (') come carattere di virgolette.

Nota

Se i valori letterali separatori dei nomi del provider non corrispondono a questi valori predefiniti, il provider deve esporli tramite IDBInfo per consentire a SQL Server di accedere alle tabelle tramite nomi in quattro parti. Se questi valori letterali non sono esposti, è possibile usare solo query pass-through su tale provider.

Per informazioni sull'esposizione delle proprietà SQLPROP_DYNAMICSQL e SQLPROP_NESTEDQUERIES, vedere Proprietà specifiche di SQL Server.

Risoluzione dei nomi di tabella e recupero dei metadati

SQL Server risolve un dato nome di tabella remota in una query distribuita in una tabella o vista specifica in un'origine dati OLE DB. Sia gli schemi di denominazione basati su server collegati che quelli ad hoc comportano l'interpretazione di un nome in tre parti da parte del provider. Nel caso del nome basato sul server collegato, le ultime tre parti del nome in quattro parti costituiscono i nomi di catalogo, schema e oggetto. Nel caso del nome ad hoc, il terzo argomento della funzione OPENROWSET specifica un nome in tre parti che descrive i nomi di catalogo, schema e oggetto. Uno o entrambi i nomi del catalogo e dello schema possono essere vuoti. Un nome in quattro parti con un nome di catalogo vuoto e un nome di schema sarà simile a <server-name>...<object-name>. In questo caso, SQL Server usa NULL come valore corrispondente per cercare nelle tabelle del set di righe dello schema.

Le regole di risoluzione dei nomi e i passaggi di recupero dei metadati impiegato da SQL Server dipendono dal fatto che il provider supporti l'interfaccia IDBSchemaRowset nell'oggetto Session .

Se IDBSchemaRowset è supportata, vengono usati i set di righe dello schema TABLES, COLUMNS, INDEXES e TABLES_INFO dall'interfaccia IDBSchemaRowset. Il set di righe dello schema TABLES_INFO è definito in OLE DB 2.0. SQL Server limita i set di righe dello schema restituiti dall'interfaccia IDBSchemaRowset per cercare le righe dello schema che corrispondono alle parti del nome della tabella remota specificata. Di seguito sono riportate le regole correlate alle restrizioni supportate dal provider nei set di righe dello schema e al modo in cui SQL Server le usa per recuperare i metadati di una tabella remota:

Le restrizioni per le colonne TABLE_NAME e COLUMN_NAME sono sempre obbligatorie.
Se il provider supporta una restrizione in TABLE_CATALOG (o TABLE_SCHEMA), SQL Server usa la restrizione in TABLE_CATALOG (o TABLE_SCHEMA). Se il nome del catalogo (o dello schema) non è specificato nel nome della tabella remota, viene usato un NULL valore come valore di restrizione corrispondente. Se viene specificato un nome di catalogo o schema, il provider deve supportare la restrizione corrispondente in TABLE_CATALOG o TABLE_SCHEMA.
Il provider deve supportare la restrizione nella colonna TABLE_SCHEMA sia in TABLES che in COLUMNS, oppure su nessuno dei due. Il provider deve supportare la restrizione del nome di catalogo nei set di righe TABLES e COLUMNS oppure in nessuno dei due.
Se sono supportate restrizioni in INDEXES, il provider deve supportare la restrizione dello schema per entrambi TABLES e INDEXES o supportarli in nessuno dei due casi. Il provider deve supportare la restrizione del nome di catalogo nei set di righe TABLES e INDEXES oppure in nessuno dei due.

TABLES Dal set di righe dello schema, SQL Server recupera le TABLE_CATALOGcolonne , TABLE_SCHEMA, TABLE_NAME, TABLE_TYPE, TABLE_GUID impostando restrizioni in base alle regole precedenti.

Dal set di righe dello schema COLUMNS, SQL Server recupera le colonne TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, COLUMN_GUID, ORDINAL_POSITION, COLUMN_FLAGS, IS_NULLABLE, DATA_TYPE, TYPE_GUID, CHARACTER_MAXIMUM_LENGTH, NUMERIC_PRECISION e NUMERIC_SCALE. COLUMN_NAME, DATA_TYPEe ORDINAL_POSITION devono restituire valori non Null validi. Se DATA_TYPE è DBTYPE_NUMERIC o DBTYPE_DECIMAL, NUMERIC_PRECISION e NUMERIC_SCALE corrispondenti devono essere valori non Null validi.

Dal set di righe dello schema INDEXES facoltativo, SQL Server ricerca gli indici nella tabella remota specificata impostando le restrizioni in base alle regole precedenti. Dalle voci di indice trovate, SQL Server recupera le colonne TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, INDEX_CATALOG, INDEX_SCHEMA, INDEX_NAME, PRIMARY_KEY, UNIQUE, CLUSTERED, FILL_FACTOR, ORDINAL_POSITION, COLUMN_NAME, COLLATION, CARDINALITY e PAGES.

Dal set di righe facoltativo TABLES_INFO , SQL Server cerca informazioni aggiuntive sulla tabella remota specificata, ad esempio il supporto dei segnalibri, il tipo e la lunghezza del segnalibro. Vengono usate tutte le colonne, ad eccezione della colonna DESCRIPTION del set di righe TABLES_INFO. Le informazioni nel set di righe TABLES_INFO vengono usate come segue:

La colonna BOOKMARK_DURABILITY viene usata per implementare cursori keyset più efficienti. Se questa colonna ha un valore BMK_DURABILITY_INTRANSACTION o un valore di durabilità maggiore, SQL Server utilizza il recupero basato su segnalibro e gli aggiornamenti delle righe di una tabella remota per l'implementazione di un cursore keyset.
Le BOOKMARK_TYPEcolonne , BOOKMARK_DATA_TYPEe BOOKMARK_MAXIMUM_LENGTH vengono usate per determinare i metadati dei segnalibri in fase di compilazione delle query. Se queste colonne non sono supportate, SQL Server apre il set di righe della tabella di base durante IOpenRowset la compilazione per ottenere le informazioni sui segnalibri.

Se IDBSchemaRowset non è supportato e il nome della tabella remota include un catalogo o un nome di schema, SQL Server richiede IDBSchemaRowset e restituisce un errore. Tuttavia, se il catalogo o i nomi degli schemi non vengono forniti, SQL Server apre il set di righe che corrisponde alla tabella remota e recupera i metadati della colonna dall'interfaccia obbligatoria IColumnsInfo dell'oggetto set di righe.

SQL Server apre il set di righe corrispondente alla tabella tramite una chiamata a IOpenRowset::OpenRowset. Il nome di tabella specificato in OPENROWSET viene costruito in base alle parti del nome del catalogo, dello schema e dell'oggetto.

Ognuna delle parti del nome (catalog, schema, object name) è racchiusa con il carattere di citazione del provider (DBLITERAL_QUOTE) e poi concatenata con il carattere DBLITERAL_CATALOG_SEPARATOR e il carattere DBLITERAL_SCHEMA_SEPARATOR incorporati tra di loro. La costruzione del nome segue le regole OLE DB in IOpenRowset.
I metadati della colonna per la tabella vengono recuperati dopo IColumnsInfo::GetColumnInfo l'apertura dell'oggetto set di righe.

Se IDBSchemaRowset non è supportato con TABLESi set di righe , COLUMNSe TABLES_INFO , SQL Server apre il set di righe sulla tabella di base due volte: una volta durante la compilazione della query per recuperare i metadati e una volta durante l'esecuzione della query. Questo comportamento deve essere considerato dai provider che riscontrano problemi causati dall'apertura del set di righe, ad esempio l'esecuzione di codice che modifica lo stato di un dispositivo in tempo reale, l'invio di messaggi di posta elettronica, l'esecuzione di codice arbitrario specificato dall'utente.

Recupero delle statistiche

Se il provider supporta le statistiche di distribuzione nelle tabelle di base, SQL Server usa queste statistiche. Sono disponibili due tipi di statistiche utili per l'elaborazione di query di SQL Server:

Cardinalità di colonne (o tuple). Si tratta del numero di valori univoci presenti in una colonna o in una combinazione di colonne di una tabella. Può essere usato per stimare la selettività dei predicati rispetto alle colonne. Un provider che supporta le statistiche di distribuzione deve supportare almeno un tipo di cardinalità.
Istogrammi. Se la distribuzione dei valori non è uniforme, no. di valori univoci non è sufficiente per stimare in modo accurato la selettività dei predicati. In questo caso, è possibile specificare un istogramma che fornisce informazioni più dettagliate sulla distribuzione dei valori di colonna in una tabella.

La disponibilità delle statistiche consente a Query Optimizer di SQL Server di stimare meglio le cardinalità delle operazioni intermedie in una query, che consente di generare piani di esecuzione migliori per loro.

Il provider di OLE DB deve supportare le statistiche di distribuzione come segue:

Obbligatorio. Supportare le proprietà (1) DBPROP_TABLESTATISTICS, che indica se le cardinalità di colonna o tupla sono supportate e se gli istogrammi sono supportati e (2), DBPROP_OPENROWSETSUPPORTche indica se sono supportati gli DBPROPVAL_ORS_HISTOGRAM istogrammi.
Obbligatorio. Set di righe dello schema TABLE_STATISTICS. Il set di righe dello schema TABLE_STATISTICS elenca le statistiche disponibili in un determinato database. Include anche le cardinalità delle colonne e delle tuple nel set di righe dello schema stesso e indica se gli istogrammi sono supportati sulle colonne specifiche. Per consentire l'uso delle statistiche da parte di SQL Server, le colonne TABLE_NAME, STATISTICS_NAME, STATISTICS_TYPE, COLUMN_NAME e ORDINAL_POSITION sono obbligatorie nel set di righe dello schema. Almeno una tra COLUMN_CARDINALITY o TUPLE_CARDINALITY è obbligatoria. Se gli istogrammi sono supportati, NO_OF_RANGES è obbligatorio anche .
Facoltativo. Facoltativamente, se il provider supporta gli istogrammi, deve supportare un miglioramento del metodo IOpenRowset::OpenRowset che consente di aprire un set di righe dell'istogramma specificando DBID della statistica corrispondente.

Per informazioni complete sulle interfacce delle statistiche, vedere la specifica OLE DB 2.6.

Vincoli

Il componente Query Optimizer di SQL Server usa anche i vincoli CHECK definiti nelle tabelle di base in un'origine dati remota, se il provider OLE DB supporta il set di righe dello schema OLE DB 2.6 CHECK_CONSTRAINTS_BY_TABLE. La colonna CHECK_CLAUSE del set di righe dello schema deve restituire il predicato della clausola CHECK nella sintassi conforme a SQL-92. Il Query Optimizer utilizza le informazioni dei vincoli per eliminare o semplificare i predicati che sono sempre falsi o sempre veri per la presenza di un vincolo CHECK sulla tabella.

Gestione delle transazioni

SQL Server supporta l'accesso basato su transazioni ai dati distribuiti tramite le interfacce OLE DB ITransactionLocal (per transazioni locali) e ITransactionJoin (per le transazioni distribuite) del provider. Avviando una transazione locale nel provider, SQL Server garantisce operazioni di scrittura atomiche. Usando transazioni distribuite, SQL Server garantisce che una transazione che coinvolge più nodi abbia lo stesso risultato (commit o interruzione) in tutti i nodi. Se il provider non supporta le interfacce correlate alle transazioni OLE DB necessarie, le operazioni di aggiornamento su tale provider non sono consentite a seconda del contesto di transazione locale.

Nella tabella seguente viene descritto cosa accade quando l'utente esegue una query distribuita con le capacità del provider e il contesto di transazione locale specificati. Un'operazione di lettura su un provider si riferisce a un'istruzione SELECT oppure al momento in cui la tabella remota viene letta nella parte d'ingresso di un'istruzione SELECT INTO, INSERT, UPDATE o DELETE. Un'operazione di scrittura in un provider fa riferimento a un'istruzione INSERT, UPDATE o DELETE con una tabella remota come tabella di destinazione.

Risultati di una query distribuita in base alle capacità del provider e al contesto di transazione:

La query distribuita viene eseguita in	Il provider non supporta `ITransactionLocal`	Il provider supporta `ITransactionLocal` ma non `ITransactionJoin`	Il provider supporta `ITransactionLocal` e `ITransactionJoin`
In una transazione autonoma (senza alcuna transazione utente).	Per impostazione predefinita, sono consentite solo le operazioni di lettura. Quando l'opzione di livello del provider `Nontransacted Updates` è abilitata, sono consentite le operazioni di scrittura. Quando questa opzione è abilitata, SQL Server non può garantire l'atomicità e la coerenza sui dati del provider. Ciò può causare effetti parziali di un'operazione di scrittura che si riflettono nell'origine dati remota senza la possibilità di annullarli.	Sono consentite tutte le istruzioni in merito ai dati remoti. I cursori keyset sono di sola lettura. La transazione è locale e viene avviata nel provider con il livello di isolamento della sessione di SQL Server corrente, e il commit viene eseguito al termine della valutazione riuscita delle istruzioni. Il livello di isolamento predefinito per una sessione di SQL Server è `READ COMMITTED` a meno che non venga modificato con l'istruzione `SET TRANSACTION ISOLATION LEVEL` . Il provider deve supportare il livello di isolamento richiesto.	Sono consentite tutte le dichiarazioni. I cursori keyset sono di sola lettura. La transazione locale viene avviata nel provider con il livello di isolamento della sessione di SQL Server corrente e il commit viene eseguito al completamento della valutazione dell'istruzione.
In una transazione utente, ovvero tra `BEGIN TRAN` o `BEGIN DISTRIBUTED TRAN` e `COMMIT`.	Se il livello di isolamento della transazione è `READ COMMITTED` (impostazione predefinita) o inferiore, sono consentite le operazioni di lettura. Se il livello di isolamento è superiore, non è consentita alcuna query distribuita.	Sono consentite solo le operazioni di lettura. Le nuove transazioni distribuite vengono avviate sul provider con il livello di isolamento della sessione di SQL Server corrente.	Sono consentite tutte le dichiarazioni. La nuova transazione distribuita viene avviata sul provider con il livello di isolamento della sessione corrente di SQL Server e viene confermata quando si conclude la transazione dell'utente. Per le istruzioni di modifica dei dati, per impostazione predefinita SQL Server avvia una transazione nidificata nella transazione distribuita in modo che l'istruzione di modifica dei dati possa essere arrestata in determinate condizioni di errore senza arrestare la transazione circostante. Se l'opzione `XACT_ABORT SET` è attivata, SQL Server non richiede il supporto delle transazioni annidate e arresta la transazione circostante in caso di errori durante l'istruzione di modifica dei dati.

Gestione dei tipi di dati nelle query distribuite

I provider OLE DB espongono i dati in termini di tipi di dati definiti da OLE DB (indicati da DBTYPE in OLE DB). SQL Server elabora i dati esterni nel server come tipi SQL Server nativi. In questo modo si ottiene un mapping dei tipi di dati OLE DB nei tipi nativi SQL Server e viceversa quando i dati vengono usati rispettivamente da SQL Server o esportati da SQL Server. Il mapping viene eseguito in modo implicito, a meno che non sia specificato diversamente.

I tipi di dati nelle query distribuite vengono gestiti usando uno dei due metodi di mapping seguenti:

Il mapping lato consumo esegue il mapping dei tipi di dati dai tipi di dati OLE DB ai tipi di dati nativi di SQL Server sul lato consumer, quando le tabelle remote vengono visualizzate nelle SELECT istruzioni e sul lato input delle INSERTistruzioni , UPDATEe DELETE .
Il mapping lato esportazione mappa i tipi dai tipi di dati SQL Server ai tipi di dati OLE DB sul lato esportazione, quando una tabella remota appare come tabella di destinazione di un'istruzione INSERT o UPDATE.

Tabella di mapping dei tipi di dati SQL Server e OLE DB.

Tipo OLE DB	`DBCOLUMNFLAG`	Tipo di dati di SQL Server
`DBTYPE_I1` ¹		numeric(3, 0)
`DBTYPE_I2`		smallint
`DBTYPE_I4`		int
`DBTYPE_I8`		numeric(19,0)
`DBTYPE_UI1`		tinyint
`DBTYPE_UI2` ¹		numeric(5,0)
`DBTYPE_UI4` ¹		numeric(10,0)
`DBTYPE_UI8` ¹		numeric(20,0)
`DBTYPE_R4`		float
`DBTYPE_R8`		real
`DBTYPE_NUMERIC`		numeric
`DBTYPE_DECIMAL`		decimal
`DBTYPE_CY`		money
`DBTYPE_BSTR`	`DBCOLUMNFLAGS_ISFIXEDLENGTH=true` o Lunghezza > massima 4.000 caratteri	ntext
`DBTYPE_BSTR`	`DBCOLUMNFLAGS_ISFIXEDLENGTH=true`	nchar
`DBTYPE_BSTR`	`DBCOLUMNFLAGS_ISFIXEDLENGTH=false`	nvarchar
`DBTYPE_IDISPATCH`		Errore
`DBTYPE_ERROR`		Errore
`DBTYPE_BOOL`		bit
`DBTYPE_VARIANT` ¹		nvarchar
`DBTYPE_IUNKNOWN`		Errore
`DBTYPE_GUID`		uniqueidentifier
`DBTYPE_BYTES`	`DBCOLUMNFLAGS_ISLONG=true` o Lunghezza > massima 8.000	image
`DBTYPE_BYTES`	`DBCOLUMNFLAGS_ISROWVER=true`, `DBCOLUMNFLAGS_ISFIXEDLENGTH=true`, dimensioni colonna = 8 o Lunghezza massima non indicata.	Timestamp
`DBTYPE_BYTES`	`DBCOLUMNFLAGS_ISFIXEDLENGTH=true`	binary
`DBTYPE_BYTES`	`DBCOLUMNFLAGS_ISFIXEDLENGTH=true`	varbinary
`DBTYPE_STR`	`DBCOLUMNFLAGS_ISFIXEDLENGTH=true`	Char
`DBTYPE_STR`	`DBCOLUMNFLAGS_ISFIXEDLENGTH=true`	varchar
`DBTYPE_STR`	`DBCOLUMNFLAGS_ISLONG=true` o Lunghezza > massima 8.000 caratteri o Lunghezza massima non indicata.	testo
`DBTYPE_WSTR`	`DBCOLUMNFLAGS_ISFIXEDLENGTH=true`	nchar
`DBTYPE_WSTR`	`DBCOLUMNFLAGS_ISFIXEDLENGTH=false`	nvarchar
`DBTYPE_WSTR`	`DBCOLUMNFLAGS_ISLONG=true` o Lunghezza >massima 4.000 caratteri o Lunghezza massima non indicata.	ntext
`DBTYPE_UDT`		Errore
`DBTYPE_DATE`		datetime
`DBTYPE_DBDATE` ¹		datetime (conversione esplicita richiesta)
`DBTYPE_DBTIME`		datetime (conversione esplicita richiesta)
`DBTYPE_DBTIMESTAMP` ¹		datetime
`DBTYPE_ARRAY`		Errore
`DBTYPE_BYREF`		Ignorato
`DBTYPE_VECTOR`		Errore
`DBTYPE_RESERVED`		Errore

¹ Indicare una forma di conversione nella rappresentazione del tipo di SQL Server, perché non esiste un tipo di dati equivalente esatto in SQL Server. Le conversioni potrebbero comportare una perdita di precisione, sovraccarico o sottocarico. I mapping impliciti predefiniti possono essere modificati in futuro se i tipi di dati corrispondenti sono supportati dalle versioni future di SQL Server.

Nota

numeric(p,s) indica il tipo di dati SQL Server numeric con precisione p e scalabilità s. La precisione massima consentita per DBTYPE_NUMERIC e DBTYPE_DECIMAL è 38. Il provider deve supportare l'associazione alla colonna DBTYPE_BSTR come DBTYPE_WSTR durante la creazione di un accessor. DBTYPE_VARIANT le colonne vengono utilizzate come stringhe di caratteri Unicode nvarchar. È necessario il supporto per la conversione da DBTYPE_VARIANT a DBTYPE_WSTR dal provider. Si prevede che il provider implementi questa conversione come definito in OLE DB. Per altre informazioni, vedere i tipi di dati della specifica OLE DB.

Interpretare il mapping dei tipi di dati

Il mapping a un tipo di SQL Server è determinato dal tipo di dati OLE DB e dai DBCOLUMNFLAGS valori che descrivono la colonna o il valore scalare. Nel caso del set di righe dello schema COLUMNS le colonne DATA_TYPE e COLUMN_FLAGS rappresentano questi valori. Nel caso dell'interfaccia IColumnsInfo::GetColumnInfo i membri wType e dwFlags della struttura DBCOLUMNINFO rappresentano queste informazioni.

Per utilizzare il mapping lato consumo per una determinata colonna con un valore DBTYPE e DBCOLUMNFLAG specifico, cercare il tipo SQL Server corrispondente nella tabella. Le regole del tipo per le colonne delle tabelle remote nelle espressioni possono essere descritte dalla semplice regola seguente:

Un valore di colonna remota è valido in un'espressione Transact-SQL se il tipo SQL Server mappato corrispondente nella tabella è valido nello stesso contesto.

La tabella e la regola definiscono:

Confronti ed espressioni.

In generale, X <op> <remote-column> è un'espressione valida se <op> è un operatore valido per il tipo di dati X e il tipo di dati cui viene mappato <remote-column>.

Conversioni esplicite.

Convert(X, <remote-column>)è consentito se l'oggetto di esegue il DBTYPE mapping al tipo di Y dati nativo (in base alla tabella precedente) e la conversione esplicita da Y a X è <remote-column> consentita.

Per convertire i dati remoti in un tipo di dati nativo non predefinito, è necessario che gli utenti usino una conversione esplicita.

Per usare il mapping lato esportazione nel caso di istruzioni UPDATE e INSERT in tabelle remote, mappare i tipi di dati nativi di SQL Server ai tipi di dati OLE DB usando la stessa tabella. Il mapping di un tipo SQL Server S1 a un tipo OLE DB T specifico è consentito solo se si verifica una delle condizioni seguenti:

Il mapping corrispondente è disponibile direttamente nella tabella di mapping.
Esiste una conversione implicita consentita di in un altro tipo S2 di S1 SQL Server, che S2 esegue il mapping al tipo T nella tabella di mapping.

Gestione di oggetti di grandi dimensioni (LOB)

Come indicato nella tabella di mapping, se le colonne di tipo DBTYPE_STR, DBTYPE_WSTRo DBTYPE_BSTR segnalano anche DBCOLUMNFLAGS_ISLONGo se la lunghezza massima supera i 4.000 caratteri (o se non viene segnalata alcuna lunghezza massima), SQL Server li considera come una colonna di testo o ntext in base alle esigenze. Analogamente, per DBTYPE_BYTES le colonne, se DBCOLUMNFLAGS_ISLONG è impostata o se la lunghezza massima è superiore a 8.000 byte (o se la lunghezza massima non viene segnalata), le colonne vengono considerate come colonne di immagine . le colonne text, ntext e image sono denominate colonne LOB.

SQL Server non espone la funzionalità full-text e image nei LOB da un provider OLE DB. TEXTPTRS non sono supportati in oggetti di grandi dimensioni da un provider OLE DB; di conseguenza, nessuna delle funzionalità correlate è supportata, ad esempio, la TEXTPTR funzione di sistema e READTEXTle istruzioni , WRITETEXTe UPDATETEXT . SELECT Le istruzioni che recuperano intere colonne LOB sono supportate, come sono UPDATE e INSERT le istruzioni per intere colonne di oggetti di grandi dimensioni nelle tabelle remote.

SQL Server usa le interfacce di archiviazione strutturate nelle colonne LOB se supportate dal provider. Le interfacce di archiviazione strutturate in ordine crescente di preferenza e funzionalità sono le seguenti: ISequentialStream, Istream o ILockBytes. Se una o più di queste interfacce sono supportate, il provider deve restituire DBPROPVAL_OO_BLOB come valore della DBPROP_OLEOBJECTS proprietà quando viene eseguita una query tramite l'interfaccia IDBProperties . Inoltre, il provider deve indicare il supporto per le interfacce supportate nella proprietà DBPROP_STRUCTUREDSTORAGE.

Se il provider non supporta alcuna interfaccia di archiviazione strutturata nelle colonne LOB, SQL Server materializza questa interfaccia autonomamente e le espone comunque come colonne text, ntext o image .

Accedere alle colonne LOB

Se il provider supporta una delle interfacce di archiviazione strutturate, SQL Server esegue i passaggi seguenti per recuperare le colonne LOB durante l'esecuzione della query:

Prima di aprire il set di righe tramite IOpenRowset::OpenRowset, SQL Server richiede il supporto per una o più interfacce di archiviazione strutturate (ISequentialStream, Istream e ILockBytes) nelle colonne di grandi oggetti (LOB). La prima interfaccia supportata dal provider è obbligatoria; le interfacce aggiuntive vengono richieste come "set if cheap" impostando l'elemento dwOptions della struttura corrispondente DBPROP su DBPROPOPTIONS_SETIFCHEAP. Ad esempio, se un provider supporta sia ISequentialStream che ILockBytes, ISequentialStream è obbligatorio, mentre ILockBytes può essere impostato se conveniente.
Dopo aver aperto il set di righe, SQL Server usa IRowsetInfo::GetProperties per identificare le interfacce effettive disponibili nel set di righe. Viene usata l'ultima interfaccia o la più adatta restituita dal provider. Quando SQL Server crea una funzione di accesso sulla colonna di oggetti di grandi dimensioni, la colonna viene associata come DBTYPE_IUNKNOWN con l'elemento iid della DBOBJECT struttura nell'associazione impostata sull'interfaccia .

Leggere da colonne LOB

Utilizzare il puntatore dell'interfaccia per l'interfaccia di archiviazione strutturata richiesta restituita nel buffer di riga tramite IRowset::GetData per leggere dalla colonna dell'oggetto di grandi dimensioni. Se il provider non supporta più LOB aperti contemporaneamente, ovvero se non supporta DBPROP_MULTIPLE_STORAGEOBJECTS, e se la riga contiene più colonne di oggetti di grandi dimensioni, SQL Server copia le colonne LOB in una tabella di lavoro locale.

`UPDATE` istruzioni e `INSERT` nelle colonne LOB

SQL Server passa al provider un puntatore a un nuovo oggetto di archiviazione anziché usare l'interfaccia fornita dal provider per modificare l'oggetto di archiviazione. Per ogni colonna LOB, il valore aggiornato o inserito in un oggetto di archiviazione viene creato con l'interfaccia di archiviazione strutturata selezionata. A seconda che si tratti di un'operazione UPDATE o INSERT , un puntatore all'oggetto di archiviazione viene passato rispettivamente al provider tramite IRowsetChange::SetData o IRowsetChange::InsertRow.

Gestione degli errori

Quando una chiamata a un metodo specifico in un provider OLE DB restituisce un codice di errore, SQL Server cerca le informazioni di errore estese del provider prima di restituire all'utente le informazioni sulla condizione di errore.

SQL Server usa l'oggetto errore OLE DB come specificato da OLE DB. Di seguito sono riportati alcuni passaggi di alto livello:

Quando una chiamata al metodo restituisce un codice di errore dal provider, SQL Server cerca l'interfaccia ISupportErrorInfo. Se l'interfaccia è supportata, SQL Server chiama ISupportErrorInfo::InterfaceSupportsErrorInfo per verificare se gli oggetti errore sono supportati dall'interfaccia che ha generato il codice di errore.
Se gli oggetti errore sono supportati dall'interfaccia, SQL Server chiama la funzione GetErrorInfo per ottenere un puntatore all'interfaccia IErrorInfo nell'oggetto errore corrente.
SQL Server usa l'interfaccia IErrorInfo per ottenere un puntatore all'interfaccia IErrorRecords.
SQL Server usa IErrorRecords per riprodurre a ciclo continuo tutti i record degli errori nell'oggetto e ottenere il testo del messaggio di errore corrispondente a ogni record.

Per ulteriori informazioni su come viene utilizzato l'oggetto di errore del provider, consultare la documentazione OLE DB.

Sicurezza

Quando un utente si connette a un provider OLE DB, il provider richiede in genere un ID utente e una password, a meno che l'utente non voglia essere autenticato come utente di sicurezza integrato. Nel caso di query distribuite, SQL Server agisce come utente del provider OLE DB per conto dell'account di accesso SQL Server che esegue la query distribuita. SQL Server mappa l'account di accesso SQL Server corrente a un ID utente e una password nel server collegato.

Queste mappature possono essere specificate dall'utente per un determinato server collegato e possono essere configurate e gestite dalle stored procedure di sistema sp_addlinkedsrvlogin e sp_droplinkedsrvlogin. Impostando le proprietà del gruppo di inizializzazione DBPROP_AUTH_USERID e DBPROP_AUTH_PASSWORD tramite IDBProperties::SetProperties, l'ID utente e la password determinati dal mapping vengono passati al provider durante la connessione.

Quando un client si connette a SQL Server tramite l'autenticazione di Windows e se l'account di accesso ha un mapping self configurato tramite sp_addlinkedsrvlogin, SQL Server tenta di rappresentare il contesto di sicurezza del client e imposta la proprietà DBPROP_AUTH_INTEGRATED nel provider durante la connessione. Questo processo viene chiamato delega.

Dopo aver determinato il contesto di sicurezza usato per la connessione, l'autenticazione del contesto di sicurezza e il controllo delle autorizzazioni per il contesto negli oggetti dati dell'origine dati sono interamente responsabilità del provider OLE DB.

Per altre informazioni, vedere sp_addlinkedserver e sp_droplinkedsrvlogin.

Scenari di esecuzione di query

Durante la valutazione di una query distribuita, SQL Server interagisce con il provider OLE DB in uno o più di questi scenari:

Query remota
Accesso indicizzato
Analisi di tabelle pure
Istruzioni UPDATE e DELETE
Istruzione INSERT
Query pass-through

Query remota

SQL Server genera una query SQL che valuta una parte della query originale che può essere valutata interamente dal provider. Questo scenario è possibile solo contro i fornitori di comandi SQL. La misura in cui SQL Server esegue il push delle operazioni nel provider generando una query SQL dipende dalla grammatica SQL supportata dal provider. Il provider deve indicare il livello di supporto SQL tramite gli elementi seguenti:

Indicando il livello di supporto SQL Minimum, ODBC Core o SQL-92 Entry level tramite la proprietà DBPROP_SQLSUPPORT. Il livello di sintassi SQL Minimum è un nuovo livello supportato in SQL Server che consente a SQL Server di inviare query remote a provider semplici che supportano un subset di SQL semplice. Questo livello include un'istruzione di base SELECT che non include sottoquery, più tabelle nella FROM clausola (quindi nessun join) e GROUP BY. Per il sottoinsieme della grammatica SQL utilizzato da SQL Server per la generazione di query remote contro i provider dei livelli di sintassi di ciascuno di questi, consultare Sottoinsieme SQL utilizzato per la generazione di query remote.
Supportando varie proprietà specifiche di SQL Server per indicare il supporto per singole funzionalità SQL che non sono altrimenti incluse nel livello di sintassi come indicato da DBPROP_SQLSUPPORT. L'elenco delle proprietà e il modo in cui vengono usati da SQL Server vengono descritti più avanti in questa sezione.

SQL Server usa l'esecuzione di query con parametri con un punto interrogativo (?) come marcatore di parametro nella stringa Transact-SQL. L'esecuzione di query parametrizzate viene utilizzata con i provider SQL Server, Microsoft Jet e Oracle OLE DB. Rispetto ad altri provider, viene usata l'esecuzione di query con parametri se il provider supporta ICommandWithParameters nell'oggetto Command e viene soddisfatta almeno una delle condizioni seguenti:

Il provider indica il livello di ODBC Core del supporto SQL Server tramite la proprietà DBPROP_SQLSUPPORT.
Il provider indica il supporto per il marcatore di parametro punto interrogativo (?) supportando la SQLPROP_DYNCMICSQL proprietà specifica di SQL Server tramite IDBPProperties. Per maggiori dettagli, consulta la sezione successiva sulle proprietà del fornitore.
L'amministratore imposta l'opzione del provider Dynamic Parameters nel provider per fare in modo che SQL Server generi query con parametri.

Quando SQL Server genera il testo SQL da eseguire in remoto, i nomi delle tabelle e delle colonne sono racchiusi tra i caratteri di citazione del provider, come riportato attraverso il literal DBLITERAL_QUOTE dell'interfaccia IDBInfo. Se questo valore letterale non è supportato, i nomi di tabella e di colonna non sono racchiusi tra virgolette.

Se il provider supporta l'esecuzione di query con parametri, SQL Server usa una strategia di esecuzione di query con parametri per valutare un join di una tabella remota con una tabella locale. La query con parametri viene eseguita ripetutamente per i valori dei parametri generati da ogni riga della tabella locale. Questa strategia riduce il numero di righe recuperate dal provider ed è utile quando una tabella locale con poche righe viene unita a una tabella remota con un numero elevato di righe. Questa strategia di join remoto può essere applicata con l'indicazione di ottimizzazione del join REMOTE. Per altre informazioni sull'esecuzione di query con parametri, vedere Procedura: Eseguire query con parametri.

Di seguito sono riportati i passaggi principali contro il provider nello scenario di query remota.

SQL Server crea un oggetto Command dall'oggetto Session usando IDBCreateCommand::CreateCommand.
Se l'opzione di configurazione del server Remote Query Timeout è impostata su un valore > 0, SQL Server imposta la proprietà DBPROP_COMMANDTIMEOUT per l'oggetto Command sullo stesso valore tramite ICommandProperties::SetProperties. È necessario chiamare ICommand::SetCommandText per impostare il testo del comando sulla stringa Transact-SQL generata.
SQL Server chiama ICommandPrepare::Prepare per preparare il comando. Se il provider non supporta questa interfaccia, SQL Server continua con il passaggio 4.
Se la query generata è con parametri, SQL Server usa ICommandWithParameters::SetParameterInfo per descrivere i parametri e IAccessor::CreateAccessor per creare funzioni di accesso per i parametri.
SQL Server chiama ICommand::Execute per eseguire il comando e creare il set di righe.
SQL Server usa l'interfaccia IRowset per esplorare e usare righe della tabella. Usare IRowset::GetNextRows per recuperare le righe, IRowset::RestartPosition per tornare all'inizio del set di righe e IRowset::ReleaseRows per rilasciare le righe.

Proprietà del provider di interesse per l'esecuzione di query remote

Se il provider supporta le funzionalità SQL non coperte dal livello di sintassi segnalato in DBPROP_SQLSUPPORT, può indicare l'uso di varie proprietà specifiche del provider.

SQLPROP_GROUPBY. Questa proprietà è adatta ai provider che supportano il livello SQL-Minimum. Questa proprietà indica che il provider supporta le GROUP BY clausole e HAVING nell'istruzione SELECT . Inoltre, questa proprietà indica anche che il provider supporta le cinque funzioni MINdi aggregazione seguenti, , MAXSUM, COUNTe AVG. Il provider potrebbe non supportare DISTINCT l'argomento di queste funzioni di aggregazione.
SQLPROP_SUBQUERIES. Questa proprietà è adatta ai provider che supportano il livello SQL-Minimum. La proprietà indica che il provider supporta le sottoquery come specificato dal livello di base di SQL-92. Sono incluse le sottoquery nell'elenco SELECT e nella clausola WHERE con supporto per le sottoquery correlate e gli operatori IN, EXISTS, ALL e ANY.
SQLPROP_DATELITERALS. Questa proprietà è di interesse per qualsiasi provider, inclusi quelli che supportano il livello di ingresso SQL-92. Il supporto per la sintassi letterale standard per i valori letterali datetime non fa parte del livello di ingresso di SQL-92. Questa proprietà specifica di SQL Server indica che il provider supporta la sintassi dei valori letterali datetime come specificato dallo standard SQL-92.
SQLPROP_ANSILIKE. Questa proprietà interessa ai provider che supportano il livello SQL-Minimum. Questa proprietà indica che il provider supporta l'operatore LIKE in base al livello di ingresso di SQL-92 ('%' e '_' come caratteri jolly). Ciò è utile rispetto a un provider che supporta il livello di SQL-Minimum perché il livello di SQL-Minimum non include LIKE il supporto.
SQLPROP_INNERJOIN. Questa proprietà è adatta ai provider che supportano il livello SQL-Minimum. La proprietà indica il supporto per più tabelle nella clausola FROM. Ciò è utile rispetto a un provider che supporta solo il livello di SQL-Minimum perché il livello di SQL-Minimum non include il supporto per i join. Questo non indica il supporto per parole chiave esplicite JOIN e non indica il supporto per OUTER i join. Indica solo il supporto di join impliciti tramite un elenco di tabelle nella clausola FROM.
SQLPROP_DYNAMICSQL. Indica il supporto per ? come marcatore di parametro. Il marcatore di parametro deve essere supportato al posto di un elemento scalare in una clausola WHERE o nell'elenco SELECT. Il supporto per i marcatori di parametro ? consente a SQL Server di inviare query con parametri al provider.
SQLPROP_NESTEDQUERIES. Indica il supporto per s annidato SELECTnella FROM clausola , ad esempio SELECT * FROM (SELECT * FROM T)). In molti casi SQL Server usa istruzioni SELECT nidificate nella clausola FROM di una query quando genera le stringhe di query da eseguire in modalità remota. Poiché il supporto annidato SELECT non è richiesto dal livello di ingresso di SQL-92, SQL Server non delega le query con istruzioni annidate SELECT al provider, a meno che il provider non imposti anche questa proprietà. In alternativa, l'amministratore può anche impostare l'opzione del provider Nested Queries per fare generare a SQL Server query nidificate contro il provider.

Il provider può supportare queste proprietà con un set di proprietà specifico di SQL Server denominato SQLPROPSET_OPTHINTS e avere valori PROPID definiti. Il set di proprietà SQLPROPSET_OPTHINTS e le due proprietà vengono definite usando le costanti seguenti:

extern const GUID SQLPROPSET_OPTHINTS = { 0x2344480c, 0x33a7, 0x11d1, { 0x9b, 0x1a, 0x0, 0x60, 0x8, 0x26, 0x8b, 0x9e } };
enum SQLPROPERTIES {
SQLPROP_NESTEDQUERIES = 0x4,
SQLPROP_DYNAMICSQL = 0x5,
SQLPROP_GROUPBY = 0x6,
SQLPROP_DATELITERALS = 0x7,
SQLPROP_ANSILIKE = 0x8,
SQLPROP_INNERJOIN = 0x9,
SQLPROP_SUBQUERIES = 0x10
};

Implicazioni relative al set di caratteri e all'ordinamento

SQL Server supporta la specifica di una Collation per i dati di tipo carattere a livello di singola colonna. Le regole di confronto includono sia il set di caratteri che la specifica dell'ordinamento per i dati di tipo carattere non Unicode (colonne char e varchar ). Per i dati Unicode (colonne nchar e nvarchar ), le regole di confronto specificano solo l'ordinamento.

SQL Server delega i confronti di stringhe al provider solo se il set di caratteri (per i dati non Unicode), l'ordinamento e la semantica di confronto di stringhe usati dal server collegato corrispondono a quelli usati dal server locale.

Nel caso di server collegati SQL Server, SQL Server determina automaticamente la compatibilità delle regole di confronto. Per gli altri provider, l'amministratore deve indicare a SQL Server le impostazioni di confronto dei dati di testo di un determinato server collegato. In SQL Server è supportata una nuova opzione di server collegato denominata Collation Name. Se l'amministratore determina che la semantica delle regole di confronto adottata dal server collegato corrisponde a una delle regole di confronto standard di SQL Server, può impostare l'opzione Collation Name su tale nome delle regole di confronto. L'opzione Collation Name può essere impostata usando la stored procedure di sistema sp_serveroption. L'opzione deve essere impostata solo se vengono soddisfatte entrambe le condizioni seguenti:

L'ordinamento e il set di caratteri remoti corrispondono alle regole di confronto SQL Server specificate.
La semantica di confronto di stringhe usata dal provider OLE DB segue le specifiche standard SQL-92 o in modo equivalente la semantica di confronto di SQL Server.

L'opzione Regole di confronto compatibili supportata in SQL Server 7.0 è ancora supportata per ragioni di compatibilità con le versioni precedenti. L'impostazione su true equivale all'impostazione dell'opzione Nome regole di confronto sulle regole di confronto predefinite del master database di SQL Server. Le nuove applicazioni devono usare l'opzione Nome di confronto anziché l'opzione confronto compatibile.

Accesso indicizzato

SQL Server usa un indice esposto dal provider per valutare determinati predicati della query distribuita. Questo scenario è possibile solo contro i provider di indici e quando l'utente imposta l'opzione del provider Index as Access Path. Di seguito sono riportati i principali passaggi di livello elevato che SQL Server esegue nel provider quando viene usato un indice per l'esecuzione di una query:

Apre il set di righe dell'indice tramite IOpenRowset::OpenRowset con il nome di tabella e il nome di indice completi. I nomi di tabella e di indice completi vengono generati come descritto in precedenza nello scenario di query remota.
Apre il set di righe della tabella di base tramite IOpenRowset::OpenRowset con il nome di tabella completo.
Imposta gli intervalli nel set di righe dell'indice in base al predicato della query tramite IRowsetIndex::SetRange.
Esegue la scansione delle righe del set di righe dell'indice tramite IRowset sul set di righe dell'indice.
Usa la colonna segnalibro delle righe di indice recuperate per recuperare le righe corrispondenti del set di righe della tabella di base tramite IRowsetLocate::GetRowsByBookmark.

Le proprietà del set di righe DBPROP_IRowsetLocate e DBPROP_BOOKMARKS sono obbligatorie nel set di righe aperto nella tabella di base.

Scansioni di tabelle pure

SQL Server esegue la scansione dell'intera tabella remota del provider ed esegue la valutazione delle query in locale. Il set di righe corrispondente alla tabella viene aperto tramite una chiamata a IOpenRowset::OpenRowset. SQL Server costruisce il nome di tabella specificato in OPENROWSET in base alle parti del nome catalogo, schema e oggetto come segue:

Ognuna delle parti del nome viene racchiusa tra virgolette del provider (DBLITERAL_QUOTE) e quindi concatenata con il DBLITERAL_CATALOG_SEPARATOR carattere incorporato tra di esse.
Dopo l'apertura dell'oggetto set di righe, SQL Server usa l'interfaccia IColumnsInfo per verificare che i metadati in fase di esecuzione corrispondano ai metadati in fase di compilazione per la tabella.
SQL Server usa l'interfaccia IRowset per esplorare e usare righe della tabella. Usare IRowset::GetNextRows per recuperare le righe, IRowset::RestartPosition per tornare all'inizio del set di righe e IRowset::ReleaseRows per rilasciare le righe.

`UPDATE`istruzioni e `DELETE`

Per aggiornare o eliminare una tabella remota da una query distribuita SQL Server, è necessario che siano soddisfatte le condizioni seguenti:

Il provider deve supportare l'utilizzo di segnalibri nel set di righe aperto tramite IOpenRowset nella tabella da aggiornare o eliminare.
Il provider deve supportare le interfacce IRowsetLocate e IRowsetChange nel set di righe aperto tramite IOpenRowset nella tabella da aggiornare o eliminare.
L'interfaccia IRowsetChange deve supportare i metodi di aggiornamento (SetData) ed eliminazione (DeleteRows).
Se il provider non supporta ITransactionLocalle istruzioni e UPDATEDELETE sono consentite solo se l'opzione Non-transacted è impostata per tale provider e se l'istruzione non si trova in una transazione utente.
Se il provider non supporta ITransactionJoin, un'istruzione UPDATE o DELETE è consentita solo se non si trova in una transazione utente.

Nel set di righe aperto nella tabella aggiornata sono obbligatorie le proprietà del set di righe seguenti: DBPROP_IRowsetLocate, DBPROP_IRowsetChange e DBPROP_BOOKMARKS. La proprietà del set di righe DBPROP_UPDATABILITY è impostata su DBPROPVAL_UP_CHANGE o DBPROPVAL_UP_DELETE, a seconda che l'operazione eseguita sia rispettivamente UPDATE o DELETE.

Vengono eseguiti i passaggi generali seguenti sul provider per l'elaborazione di un'operazione UPDATE o DELETE :

SQL Server apre il set di righe della tabella di base attraverso l'interfaccia IOpenRowset. SQL Server richiede le proprietà indicate in precedenza nel set di righe.
SQL Server determina il set di righe valide da aggiornare o eliminare.
SQL Server usa i segnalibri per posizionarsi sulle righe qualificate attraverso l'interfaccia IRowsetLocate.
Utilizzare IRowsetChange::SetData per le operazioni UPDATE o IRowsetChange::DeleteRows per le operazioni di eliminazione, al fine di apportare le modifiche necessarie alle righe qualificate.

`INSERT` istruzione

Le condizioni per il supporto delle istruzioni INSERT in una tabella remota sono meno rigorose di quelle per le istruzioni UPDATE e DELETE.

Il provider deve supportare IRowsetChange::InsertRow nel set di righe aperto sulla tabella di base in cui si stanno inserendo i dati.
Se il provider non supporta ITransactionLocal, INSERT le istruzioni sono consentite solo se l'opzione Non-transacted updates è impostata per il server collegato e se l'istruzione non si trova in una transazione utente.
Se il provider non supporta ITransactionJoin, INSERT le istruzioni sono consentite solo se non si trovano in una transazione utente.

SQL Server usa IOpenRowset::OpenRowset per aprire un set di righe nella tabella di base e chiama IRowsetChange::InsertRow per inserire nuove righe nel set di righe di base.

Query di passaggio

Questo scenario è simile allo scenario nella query remota, ad eccezione del fatto che il testo del comando specificato a ICommand è una stringa di comando inviata dall'utente e non viene interpretata da SQL Server. SQL Server usa DBGUID_DEFAULT come identificatore del dialetto quando chiama ICommandText::SetCommandText. DBGUID_DEFAULT indica che il provider deve usare il relativo dialetto predefinito. Se il testo del comando restituisce più di un set di risultati, ad esempio se il comando richiama una stored procedure che restituisce più set di risultati, SQL Server usa solo il primo set di risultati del comando.

Per un elenco di tutte le interfacce OLE DB usate da SQL Server, vedere Interfacce OLE DB usate da SQL Server.

Conclusione

Microsoft SQL Server offre il set di strumenti più affidabile per accedere ai dati da origini dati eterogenee. Grazie alla conoscenza delle interfacce OLE DB esposte da SQL Server, gli sviluppatori possono esercitare un elevato livello di controllo e complessità nelle query distribuite.

Interfacce OLE DB utilizzate da SQL Server

Nella tabella seguente sono elencate tutte le interfacce OLE DB usate da SQL Server. La colonna Obbligatorio indica se l'interfaccia fa parte della funzionalità OLE DB minima richiesta da SQL Server o se è facoltativa. Se una determinata interfaccia non è contrassegnata come necessaria, SQL Server può comunque accedere al provider, ma alcune funzionalità o ottimizzazioni specifiche di SQL Server non sono possibili rispetto al provider.

Nel caso delle interfacce facoltative, la colonna Scenari indica uno o più dei sei scenari in cui viene usata l'interfaccia specificata. Ad esempio, l'interfaccia IRowsetChange sui set di righe di tabella di base è un'interfaccia facoltativa. Questa interfaccia viene usata negli UPDATE scenari di istruzioni e istruzioni e DELETEINSERT . Se questa interfaccia non è supportata, UPDATEle istruzioni , DELETEe INSERT non possono essere supportate in tale provider. Per alcune delle altre interfacce facoltative è indicato “prestazioni” nella colonna Scenari a indicare che l'interfaccia produce prestazioni generali migliori. Ad esempio, se l'interfaccia IDBSchemaRowset non è supportata, SQL Server deve aprire il set di righe due volte: una per i metadati e una volta per l'esecuzione della query. Grazie al supporto di IDBSchemaRowset, le prestazioni di SQL Server risultano migliorate.

Oggetto	Interfaccia	Obbligatorio	Commenti	Scenari
Oggetto origine dati	`IDBInitialize`	Sì	Inizializzare e impostare il contesto dei dati e di sicurezza.
	`IDBCreateSession`	Sì	Creare un oggetto sessione del database.
	`IDBProperties`	Sì	Ottenere informazioni sulle funzionalità del provider, impostare le proprietà di inizializzazione, la proprietà obbligatoria: `DBPROP_INIT_TIMEOUT`.
	`IDBInfo`	NO	Ottieni valore letterale di citazione, catalogo, nome, parte, separatore, carattere e così via.	Query remota.
Oggetto sessione DB	`IDBSchemaRowset`	NO	Ottenere i metadati di tabella/colonna. Set di righe necessari: `TABLES`, `COLUMNS`, `PROVIDER_TYPES`; altri set di righe usati se disponibili: `INDEXES`, `TABLE_STATISTICS`.	Prestazioni, accesso indicizzato.
	`IOpenRowset`	Sì	Aprire un set di righe in una tabella, un indice o un istogramma.
	`IGetDataSource`	Sì	Utilizzare per tornare al DSO da un oggetto sessione del database.
	`IDBCreateCommand`	NO	Usare per creare un oggetto comando (query) per i provider che supportano l'esecuzione di query.	Query remota, query passante.
	`ITransactionLocal`	NO	Usare per gli aggiornamenti transazionali.	Istruzioni `UPDATE`, `DELETE` e `INSERT`.
	`ITransactionJoin`	NO	Usare per il supporto di transazioni distribuite.	Istruzioni `UPDATE`, `DELETE` e `INSERT` se in una transazione utente.
Oggetto insieme di righe	`IRowset`	Sì	Eseguire la scansione delle righe.
	`IAccessor`	Sì	Associare alle colonne di un set di righe.
	`IColumnsInfo`	Sì	Ottenere informazioni sulle colonne di un set di righe.
	`IRowsetInfo`	Sì	Si ottengono informazioni sulle proprietà di un set di righe.
	`IRowsetLocate`	NO	Necessaria per le operazioni `UPDATE`/`DELETE` e per eseguire ricerche basate su indice; usata per ricercare le righe in base a segnalibri.	Istruzioni di accesso indicizzato, `UPDATE`, e `DELETE` .
	`IRowsetChange`	NO	Necessaria per `INSERTS`/`UPDATES`/ `DELETES` in un set di righe. I set di righe sulle tabelle di base devono supportare questa interfaccia per `INSERT`le istruzioni , `UPDATE`e `DELETE` .	Istruzioni `UPDATE`, `DELETE` e `INSERT`.
	`IConvertType`	Sì	Usare per verificare se il set di righe supporta le conversioni di tipi di dati specifici nelle colonne.
Indice	`IRowset`	Sì	Eseguire la scansione delle righe.	Accesso indicizzato, prestazioni.
	`IAccessor`	Sì	Associare alle colonne di un set di righe.	Accesso indicizzato, prestazioni.
	`IColumnsInfo`	Sì	Ottenere informazioni sulle colonne di un set di righe.	Accesso indicizzato, prestazioni.
	`IRowsetInfo`	Sì	Si ottengono informazioni sulle proprietà di un set di righe.	Accesso indicizzato, prestazioni.
	`IRowsetIndex`	Sì	Necessaria solo per i set di righe in un indice; usata per la funzionalità di indicizzazione (impostazione dell'intervallo, ricerca).	Accesso indicizzato, prestazioni.
Comando	`ICommand`	Sì		Query remota, query passante.
	`ICommandText`	Sì	Usare per definire il testo della richiesta.	Query remota, query passante.
	`IColumnsInfo`	Sì	Usare per ottenere i metadati di colonna per i risultati della query.	Query remota, query passante.
	`ICommandProperties`	Sì	Usare per specificare le proprietà obbligatorie nei set di righe restituiti dal comando.	Query remota, query passante.
	`ICommandWithParameters`	NO	Da usare per eseguire query parametrizzate.	Prestazioni della query remota.
	`ICommandPrepare`	NO	Usare per preparare un comando per ottenere i metadati (usati nelle query pass-through, se disponibili).	Prestazioni della query remota.
Oggetto di errore	`IErrorRecords`	Sì	Utilizzare per ottenere un puntatore a un'interfaccia `IErrorInfo` che corrisponde a un singolo record di errore.
	`IErrorInfo`	Sì	Utilizzare per ottenere un puntatore a un'interfaccia `IErrorInfo` che corrisponde a un singolo record di errore.
Qualsiasi oggetto	`ISupportErrorInfo`	NO	Utilizzare per verificare se una determinata interfaccia supporta gli oggetti di errore.

Nota

L'oggetto Index , Command l'oggetto e Error l'oggetto non sono obbligatori. Tuttavia, se sono supportate, le interfacce elencate sono obbligatorie come specificato nella colonna Obbligatorio.

Subset SQL usato per la generazione di query remote

Il subset SQL che il componente Query Processor di SQL Server genera in un provider di comandi SQL dipende dal livello di sintassi supportato dal provider, come indicato dalla proprietà DBPROP_SQLSUPPORT.

Provider di comandi SQL che supportano SQL Entry level o ODBC Core

SQL Server usa il seguente sottoinsieme del linguaggio SQL per le query valutate dai provider di comandi SQL che supportano il livello Entry di SQL-92 o ODBC Core:

Istruzioni SELECT con le clausole SELECT, FROM, WHERE, GROUP BY, UNION, UNION ALL, ORDER BY DESC, ASC e HAVING.
UNION e UNION ALL sono generati solo per i provider che supportano il livello di ingresso SQL-92, non per quelli che supportano ODBC Core.
Clausola SELECT:
- Sottoquery scalari nell'elenco SELECT.
- Alias di colonna senza la parola chiave AS.
Clausola FROM:
- Le parole chiave di join esplicite non vengono usate; I nomi di tabella delimitati da virgole vengono usati per specificare inner join e i outer join non vengono specificati nelle query remote.
- Query annidate della forma FROM ( <nested query> ) <alias>.
- Alias di tabella senza usare la parola chiave AS.
La clausola WHERE usa sottoquery con NOTEXISTS, ANY, ALL.
Espressioni:
- Funzioni di aggregazione usate: MIN([DISTINCT]), MAX([DISTINCT]), COUNT([DISTINCT]), SUM([DISTINCT]), AVG([DISTINCT]) e COUNT(*).
- Operatori di confronto: <, =, <=, >, <>, >=, IS NULL e IS NOT NULL.
- Operatori booleani: AND, OR e NOT.
- Operatori aritmetici: +, -, * e /.
Costanti:
- I valori letterali numerici e monetari sono sempre racchiusi tra ( ).
- I valori letterali carattere sono delimitati da ' '.

Provider di comandi SQL che supportano il livello SQL Minimum

Per i provider di comandi SQL che supportano il livello SQL Minimum, SQL Server genera codice SQL utilizzando la seguente grammatica.

Questa grammatica è stata derivata usando la grammatica SQL Minimum descritta in ODBC 3.0. Tutte le differenze rispetto a questa grammatica sono evidenziate. Gli elementi visualizzati in *bold italics* sono gli elementi aggiunti alla grammatica SQL Minimum descritta in ODBC 3.0. Gli elementi visualizzati come eliminati in verde sono gli elementi rimossi dalla grammatica.

<select_statement> ::=

SELECT [ ALL | DISTINCT ] <select_list> FROM <table_reference_list> [ WHERE <search_condition> ] [ <order_by_clause> ]

SELECT clause

select_list ::= * | <select_sublist> [ , <select_sublist> ] ...

<select_sublist> ::= expression [ <alias> ]

<alias> ::= <user_defined_name>

FROM clause

<table_reference_list> ::= <table_reference>

<table_identifier> ::= <user_defined_name>

<table_name> ::= <table_identifier>

<table_reference> ::= <table_name>

WHERE clause

<search_condition> ::= <boolean_term> [ OR <search_condition> ]

<boolean_term> ::= <boolean_factor> [ AND <boolean_term> ]

<boolean_factor> ::= [ NOT ] <boolean_primary>

<boolean_primary> ::= <comparison_predicate> | ( <search_condition> )

<comparison_predicate> ::= <expression> <comparison_operator expression>
                           | expression IS [ NOT ] NULL

comparison_operator ::= < | > | <= | >= | = | <>

ORDER BY <order_by_clause>

<order_by_clause> ::= ORDER BY <sort_specification> [ , <sort_specification> ] ...

<sort_specification> ::= { | column_name } [ ASC | DESC ]

Elementi sintattici comuni

<expression> ::= <term> | <expression> { + | - } <term>

<term> ::= <factor> | <term> { * | / } <factor>

<factor> ::= [ + | - ] <primary>

<primary> ::= <column_name>
              | literal
              | ( <expression> )

<column_name> ::= [ <table_name>. ] <column_identifier>

<literal> ::= <character_string_literal>
      | <integer_literal>
      | <exact_numeric_literal>

<character_string_literal> ::= '{<character> }...'

<integer_literal> ::= [ + | - ] <unsigned_integer>

<exact_numeric_literal>::= [ + | - ] <unsigned_integer> [ period <unsigned_integer> ]

<period> <unsigned_integer>

<base_table_name> ::= <base_table_identifier>

<base_table_identifier> ::= <user_defined_name>

<column_identifier> ::= <user_defined_name>

<user_defined_name> ::= letter [ <digit> | letter | _ ] ...

<unsigned_integer> ::= {<digit>}...

<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

period ::= .

<character> è qualsiasi carattere nel set di caratteri dell'origine driver/dati. Per includere un carattere virgolette letterale singolo (') in un <character_string_literal>, usare due caratteri letterali virgolette ('').

Proprietà specifiche di SQL Server

enum SQLPROPERTIES
       {
       SQLPROP_NOHPNEEDED = 0x1,
       SQLPROP_FREETHREADED = 0x2,
       SQLPROP_UMSENABLED = 0x3,
       SQLPROP_NESTEDQUERIES = 0x4,
       SQLPROP_DYNAMICSQL = 0x5,
       SQLPROP_GROUPBY = 0x6,
       SQLPROP_DATELITERALS = 0x7,
       SQLPROP_ANSILIKE = 0x8,
       SQLPROP_INNERJOIN = 0x9,
       SQLPROP_SUBQUERIES = 0x10,
       SQLPROP_PARALLELSCAN = 0x11,
       SQLPROP_COLUMNCOLLATION = 0x12,
       SQLPROP_CARDINALITY = 0x13,
       SQLPROP_SIMPLEUPDATES = 0x14,
       SQLPROP_SQLLIKE = 0x15,
       SQLPROP_BITREMOTING = 0x16,
       SQLPROP_UNICODELITERALS = 0x17,
       SQLPROP_USELATESTCOLLATIONVERSION = 0x18
       };

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2025-09-07

Query distribuite di Microsoft SQL Server: connettività OLE DB

Panoramica e terminologia

Categorie di provider OLE DB

Provider di comandi SQL

Provider di indici

Provider di tabelle semplici

Provider di comandi non SQL

Transact-SQL subset

Supporto cursore

Requisiti di supporto del cursore keyset

Requisiti del cursore keyset aggiornabile

Fasi di interazione del provider OLE DB

Definizione della connessione e recupero delle proprietà

Nomi basati su server collegati

Nomi ad hoc

Connettersi a un provider OLE DB

Risoluzione dei nomi di tabella e recupero dei metadati

Recupero delle statistiche

Vincoli

Gestione delle transazioni

Gestione dei tipi di dati nelle query distribuite

Interpretare il mapping dei tipi di dati

Gestione di oggetti di grandi dimensioni (LOB)

Accedere alle colonne LOB

Leggere da colonne LOB

UPDATE istruzioni e INSERT nelle colonne LOB

Gestione degli errori

Sicurezza

Scenari di esecuzione di query

Query remota

Proprietà del provider di interesse per l'esecuzione di query remote

Implicazioni relative al set di caratteri e all'ordinamento

Accesso indicizzato

Scansioni di tabelle pure

UPDATEistruzioni e DELETE

INSERT istruzione

Query di passaggio

Conclusione

Interfacce OLE DB utilizzate da SQL Server

Subset SQL usato per la generazione di query remote

Provider di comandi SQL che supportano il livello SQL Minimum

Proprietà specifiche di SQL Server

Commenti e suggerimenti

Risorse aggiuntive

`UPDATE` istruzioni e `INSERT` nelle colonne LOB

`UPDATE`istruzioni e `DELETE`

`INSERT` istruzione