Uso di ADO con SQL Server Native Client

Si applica a: SQL Server database SQL di Azure Istanza gestita di SQL di Azure Azure Synapse Analytics Piattaforma di strumenti analitici (PDW)

Importante

SQL Server Native Client (SNAC) non viene fornito con:

  • SQL Server 2022 (16.x) e versioni successive
  • SQL Server Management Studio 19 e versioni successive

SQL Server Native Client (SQLNCLI o SQLNCLI11) e il provider Microsoft OLE DB legacy per SQL Server (SQLOLEDB) non sono consigliati per lo sviluppo di nuove applicazioni.

Per i nuovi progetti, usare uno dei driver seguenti:

Per SQLNCLI fornito come componente del motore di database di SQL Server (versioni dal 2012 al 2019), vedere questa Eccezione relativa al ciclo di vita del supporto.

Per sfruttare le nuove funzionalità introdotte in SQL Server 2005 (9.x), ad esempio più set di risultati attivi (MARS), notifiche di query, tipi definiti dall'utente o il nuovo tipo di dati xml , le applicazioni esistenti che usano ActiveX Data Objects (ADO) devono usare il provider OLE DB di SQL Server Native Client come provider di accesso ai dati.

Se non è necessario usare alcuna delle nuove funzionalità introdotte in SQL Server 2005 (9.x), non è necessario usare il provider OLE DB di SQL Server Native Client; è possibile continuare a usare il provider di accesso ai dati corrente, che in genere è SQLOLEDB. Se si migliora un'applicazione esistente ed è necessario usare le nuove funzionalità introdotte in SQL Server 2005 (9.x), è consigliabile usare il provider OLE DB di SQL Server Native Client.

Nota

Se si sviluppa una nuova applicazione, è consigliabile usare ADO.NET e .NET Framework provider di dati per SQL Server anziché SQL Server Native Client per accedere a tutte le nuove funzionalità delle versioni recenti di SQL Server. Per altre informazioni sul provider di dati .NET Framework per SQL Server, vedere la documentazione di .NET Framework SDK per ADO.NET.

Per consentire ad ADO di usare nuove funzionalità delle versioni recenti di SQL Server, sono stati apportati alcuni miglioramenti al provider OLE DB di SQL Server Native Client che estende le funzionalità di base di OLE DB. Questi miglioramenti consentono l'uso nelle applicazioni ADO delle funzionalità più recenti di SQL Server e di due tipi di dati introdotti in SQL Server 2005 (9.x), ovvero 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 alla proprietà DBPROPSET_SQLSERVERDBINIT impostata per l'uso da parte delle applicazioni ADO in modo che i nuovi tipi di dati vengano esposti in modo compatibile con ADO. Inoltre, il provider OLE DB di SQL Server Native Client definisce anche una nuova parola chiave di stringa di connessione denominata DataTypeCompatibility impostata nel 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 usa il provider OLE DB di SQL Server 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 nei relativi stringa di connessione:

  • Provider=SQLNCLI11

  • DataTypeCompatibility=80

Per altre informazioni sulle parole chiave della stringa di connessione ADO supportate in SQL Server Native Client, vedere Uso delle parole chiave delle stringhe di connessione con SQL Server Native Client.

Di seguito è riportato un esempio di definizione di un stringa di connessione ADO completamente abilitato per l'uso 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  

Esempi

Le sezioni seguenti forniscono esempi di come usare ADO con il provider OLE DB di SQL Server 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, il stringa di connessione viene costruito per abilitare MARS tramite il provider OLE DB di SQL Server Native Client e quindi vengono creati due oggetti recordset per l'esecuzione usando 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 provider OLE DB di SQL Server Native Client, si ottengono più risultati attivi su una connessione.

Vedi anche

Compilazione di applicazioni con SQL Server Native Client