Utilizzo di ADO con SQL Server Native Client

Si applica a: sìSQL Server (tutte le versioni supportate) Sìdatabase SQL di Azure SìIstanza gestita di SQL di Azure sìAzure Synapse Analytics sìParallel Data Warehouse

Per sfruttare i vantaggi delle nuove funzionalità introdotte in, SQL Server 2005 (9.x) ad esempio Mars (Multiple Active Result Set), notifiche delle query, tipi definiti dall'utente (UDT) o il nuovo tipo di dati XML , le applicazioni esistenti che utilizzano ActiveX Data Objects (ADO) utilizzano il SQL Server provider OLE DB di Native client come provider di accesso ai dati.

L'uso del provider OLE DB di SQL Server 2005 (9.x) Native Client è necessario solo per utilizzare una delle caratteristiche introdotte in SQL Server. Se non si intende utilizzare tali caratteristiche, è possibile continuare a usare il provider di accesso ai dati corrente, generalmente SQLOLEDB. L'uso del provider OLE DB di SQL Server 2005 (9.x) Native Client è consigliabile se si intende potenziare un'applicazione esistente e si ha l'esigenza di utilizzare le nuove caratteristiche introdotte in SQL Server.

Nota

Se si sviluppa una nuova applicazione, è consigliabile valutare l'opportunità di utilizzare ADO.NET e il provider di dati .NET Framework per SQL Server anziché SQL Server Native Client per accedere a tutte le nuove caratteristiche delle ultime versioni di SQL Server. Per ulteriori informazioni sul provider di dati .NET Framework per SQL Server, fare riferimento alla documentazione di .NET Framework SDK per ADO.NET.

Per consentire l'utilizzo in ADO delle nuove caratteristiche delle ultime versioni di SQL Server, al provider OLE DB di SQL Server Native Client sono stati apportati alcuni miglioramenti che estendono le caratteristiche principali di OLE DB. Questi miglioramenti consentono l'uso nelle applicazioni ADO delle più recenti funzionalità di SQL Server e di due tipi di dati introdotti in SQL Server 2005 (9.x): xml e udt. Consentono inoltre di sfruttare i miglioramenti ai tipi di dati varchar, nvarchar e varbinary. SQL Server Native client aggiunge la proprietà di inizializzazione SSPROP_INIT_DATATYPECOMPATIBILITY al set di proprietà DBPROPSET_SQLSERVERDBINIT per l'utilizzo da parte delle applicazioni ADO, in modo che i nuovi tipi di dati vengano esposti in modo compatibile con ADO. Inoltre, il SQL Server provider di OLE DB di Native Client definisce anche una nuova parola chiave della stringa di connessione denominata DataTypeCompatibility impostata nella stringa di connessione.

Nota

Le applicazioni ADO esistenti possono accedere a valori XML, UDT, nonché di campi binari e di testo valore di grandi dimensioni ed eseguirne l'aggiornamento utilizzando il provider SQLOLEDB. I nuovi tipi di dati varchar(max) , nvarchar(max) e varbinary(max) di grandi dimensioni vengono restituiti rispettivamente come i tipi ADO adLongVarChar, adLongVarWChar e adLongVarBinary. Le colonne XML vengono restituite come adLongVarChar, mentre le colonne con tipo definito dall'utente vengono restituite come adVarBinary. Tuttavia, se si utilizza il SQL Server provider di OLE DB di Native Client (SQLNCLI11) anziché SQLOLEDB, è necessario assicurarsi di impostare la parola chiave DataTypeCompatibility su "80" in modo che i nuovi tipi di dati vengano mappati correttamente ai tipi di dati ADO.

Abilitazione di SQL Server Native Client da ADO

Per abilitare l'utilizzo di SQL Server native client, le applicazioni ADO dovranno implementare le parole chiave seguenti nelle stringhe di connessione:

  • Provider=SQLNCLI11

  • DataTypeCompatibility=80

Per ulteriori informazioni sulle parole chiave delle stringhe di connessione ADO supportate in SQL Server native client, vedere utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client.

Di seguito è riportato un esempio di creazione di una stringa di connessione ADO completamente abilitata per l'utilizzo con SQL Server native client, inclusa l'abilitazione della funzionalità Mars:

Dim con As New ADODB.Connection  
  
con.ConnectionString = "Provider=SQLNCLI11;" _  
         & "Server=(local);" _  
         & "Database=AdventureWorks;" _   
         & "Integrated Security=SSPI;" _  
         & "DataTypeCompatibility=80;" _  
         & "MARS Connection=True;"  
con.Open  

Esempio

Nelle sezioni seguenti vengono forniti esempi di come è possibile utilizzare ADO con il SQL Server provider di OLE DB di Native Client.

Recupero dei dati delle colonne XML

In questo esempio viene usato un recordset per recuperare e visualizzare i dati da una colonna XML nel database di esempio AdventureWorks di SQL Server.

Dim con As New ADODB.Connection  
Dim rst As New ADODB.Recordset  
Dim sXMLResult As String  
  
con.ConnectionString = "Provider=SQLNCLI11;" _  
         & "Server=(local);" _  
         & "Database=AdventureWorks;" _   
         & "Integrated Security=SSPI;" _   
         & "DataTypeCompatibility=80;"  
  
con.Open  
  
' Get the xml data as a recordset.  
Set rst.ActiveConnection = con  
rst.Source = "SELECT AdditionalContactInfo FROM Person.Contact " _  
   & "WHERE AdditionalContactInfo IS NOT NULL"  
rst.Open  
  
' Display the data in the recordset.  
While (Not rst.EOF)  
   sXMLResult = rst.Fields("AdditionalContactInfo").Value  
   Debug.Print (sXMLResult)  
   rst.MoveNext  
End While  
  
con.Close  
Set con = Nothing  

Nota

L'applicazione di filtri al recordset non è supportata con le colonne XML. Se si prova ad applicare i filtri, viene generato un errore.

Recupero dei dati delle colonne con tipo definito dall'utente

In questo esempio viene utilizzato un oggetto Command per eseguire una query SQL che restituisce un tipo definito dall'utente, vengono aggiornati i dati UDT, quindi i nuovi dati vengono nuovamente inseriti nel database. In questo esempio si presuppone che il tipo definito dall'utente (UDT) Point sia già stato registrato nel database.

Dim con As New ADODB.Connection  
Dim cmd As New ADODB.Command  
Dim rst As New ADODB.Recordset  
Dim strOldUDT As String  
Dim strNewUDT As String  
Dim aryTempUDT() As String  
Dim strTempID As String  
Dim i As Integer  
  
con.ConnectionString = "Provider=SQLNCLI11;" _  
         & "Server=(local);" _  
         & "Database=AdventureWorks;" _   
         & "Integrated Security=SSPI;" _  
         & "DataTypeCompatibility=80;"  
  
con.Open  
  
' Get the UDT value.  
Set cmd.ActiveConnection = con  
cmd.CommandText = "SELECT ID, Pnt FROM dbo.Points.ToString()"  
Set rst = cmd.Execute  
strTempID = rst.Fields(0).Value  
strOldUDT = rst.Fields(1).Value  
  
' Do something with the UDT by adding i to each point.  
arytempUDT = Split(strOldUDT, ",")  
i = 3  
strNewUDT = LTrim(Str(Int(aryTempUDT(0)) + i)) + "," + _  
   LTrim(Str(Int(aryTempUDT(1)) + i))  
  
' Insert the new value back into the database.  
cmd.CommandText = "UPDATE dbo.Points SET Pnt = '" + strNewUDT + _  
   "' WHERE ID = '" + strTempID + "'"  
cmd.Execute  
  
con.Close  
Set con = Nothing  

Abilitazione e utilizzo di MARS

In questo esempio, la stringa di connessione viene costruita per abilitare MARS tramite il SQL Server provider di OLE DB di Native client e quindi vengono creati due oggetti recordset da eseguire utilizzando la stessa connessione.

Dim con As New ADODB.Connection  
  
con.ConnectionString = "Provider=SQLNCLI11;" _  
         & "Server=(local);" _  
         & "Database=AdventureWorks;" _   
         & "Integrated Security=SSPI;" _  
         & "DataTypeCompatibility=80;" _  
         & "MARS Connection=True;"  
con.Open  
  
Dim recordset1 As New ADODB.Recordset  
Dim recordset2 As New ADODB.Recordset  
  
Dim recordsaffected As Integer  
Set recordset1 =  con.Execute("SELECT * FROM Table1", recordsaffected, adCmdText)  
Set recordset2 =  con.Execute("SELECT * FROM Table2", recordsaffected, adCmdText)  
  
con.Close  
Set con = Nothing  

Nelle versioni precedenti del provider OLE DB questo codice determinerebbe la creazione di una connessione implicita alla seconda esecuzione, in quanto per una sola connessione sarebbe possibile aprire un solo set attivo di risultati. Poiché la connessione implicita non sarebbe inserita nel pool di connessioni OLE DB, questa situazione provocherebbe overhead aggiuntivo. Con la funzionalità MARS esposta dal SQL Server provider di OLE DB di Native client, si ottengono più risultati attivi in una connessione.

Vedere anche

Compilazione di applicazioni con SQL Server Native Client