Condividi tramite


Utilizzo di ADO con SQL Server Native Client

Per sfruttare le nuove funzionalità introdotte in SQL Server 2005, come MARS (Multiple Active Result Set), notifiche delle query, tipi definiti dall'utente (UDT) o il nuovo tipo di dati xml, è necessario che nelle applicazioni esistenti che utilizzano ADO (ActiveX Data Objects) come provider di accesso ai dati venga usato il provider OLE DB di SQL Server Native Client.

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

[!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 funzionalità 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 funzionalità delle ultime versioni di SQL Server, al provider OLE DB di SQL Server Native Client sono stati apportati alcuni miglioramenti che estendono le funzionalità principali di OLE DB. Tali miglioramenti consentono l'utilizzo nelle applicazioni ADO delle più recenti funzionalità di SQL Server e di due tipi di dati introdotti in SQL Server 2005: xml e udt. Consentono inoltre di sfruttare i miglioramenti ai tipi di dati varchar, nvarchar e varbinary. In SQL Server Native Client viene aggiunta la proprietà di inizializzazione SSPROP_INIT_DATATYPECOMPATIBILITY al set di proprietà DBPROPSET_SQLSERVERDBINIT per consentirne l'utilizzo nelle applicazioni ADO, in modo che i nuovi tipi di dati siano esposti in modo compatibile con ADO. Nel provider OLE DB di SQL Server Native Client viene inoltre definita 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. Se tuttavia, si utilizza il provider OLE DB di SQL Server Native Client (SQLNCLI10) anziché SQLOLEDB, è necessario assicurarsi di impostare la parola chiave DataTypeCompatibility su "80" in modo da consentire la corretta esecuzione del mapping dei nuovi tipi di dati ai tipi di dati ADO.

Abilitazione di SQL Server Native Client da ADO

Per abilitare l'utilizzo di SQL Server Native Client, è necessario che nelle stringhe di connessione delle applicazioni ADO vengano implementate le parole chiave seguenti:

  • Provider=SQLNCLI10

  • 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 viene mostrato un esempio di stringa di connessione ADO pienamente abilitata per l'utilizzo in SQL Server Native Client con l'abilitazione del servizio MARS:

Dim con As New ADODB.Connection

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

Esempi

Nelle sezioni seguenti vengono forniti esempi di utilizzo di ADO con il provider OLE DB di SQL Server Native Client.

Recupero dei dati delle colonne XML

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

Dim con As New ADODB.Connection
Dim rst As New ADODB.Recordset
Dim sXMLResult As String

con.ConnectionString = "Provider=SQLNCLI10;" _
         & "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 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=SQLNCLI10;" _
         & "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 viene costruita la stringa di connessione per abilitare MARS mediante il provider OLE DB di SQL Server Native Client, quindi vengono creati due oggetti di recordset da eseguire utilizzando la stessa connessione.

Dim con As New ADODB.Connection

con.ConnectionString = "Provider=SQLNCLI10;" _
         & "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 il servizio MARS esposto dal provider OLE DB di SQL Server Native Client, si ottengono più risultati attivi su un'unica connessione.