Condividi tramite


Esecuzione side-by-side in ADO.NET

In .NET Framework il supporto dell'esecuzione side-by-side indica la possibilità di eseguire un'applicazione in un computer in cui sono installate più versioni di .NET Framework utilizzando esclusivamente la versione per la quale è stata compilata l'applicazione stessa. Per ulteriori informazioni sulla configurazione dell'esecuzione side-by-side, vedere Esecuzione affiancata di diverse versioni.

Un'applicazione compilata utilizzando una singola versione di .NET Framework può essere eseguita in una versione diversa di .NET Framework. Si consiglia tuttavia di compilare versioni dell'applicazione diverse per ciascuna versione di .NET Framework installata e di eseguirle separatamente. Indipendentemente dallo scenario è necessario conoscere le modifiche apportate ad ADO.NET tra una versione e l'altra per valutarne le possibili conseguenze sulla compatibilità dell'applicazione con le versioni successive o precedenti.

Compatibilità con le versioni successive e precedenti

Per compatibilità con le versioni successive si intende la possibilità di compilare un'applicazione per una versione precedente di .NET Framework, potendola comunque eseguire correttamente anche in versioni più recenti di .NET Framework. Il codice ADO.NET scritto per la versione 1.1 di .NET Framework è ad esempio compatibile con le versioni successive.

Per compatibilità con le versioni precedenti si intende la possibilità di compilare un'applicazione per una versione successiva di .NET Framework, ma di poterla eseguire correttamente anche in versioni precedenti di .NET Framework senza alcuna perdita di funzionalità. Tuttavia, ciò non vale per le funzionalità introdotte nella nuove versioni di .NET Framework.

Provider di dati .NET Framework per ODBC

Il provider di dati .NET Framework per ODBC (System.Data.Odbc) viene fornito con .NET Framework a partire dalla versione 1.1. Gli sviluppatori che utilizzano .NET Framework versione 1.0 possono scaricare il provider di dati ODBC dalla pagina Data Access and Storage del Developer Center (informazioni in lingua inglese). Lo spazio dei nomi per il provider di dati .NET Framework per ODBC scaricato è Microsoft.Data.Odbc.

Se si dispone di un'applicazione sviluppata per .NET Framework versione 1.0 che effettua la connessione a un'origine dati utilizzando il provider di dati ODBC e si desidera eseguire tale applicazione su .NET Framework versione 1.1, sarà necessario aggiornare lo spazio dei nomi per il provider di dati ODBC in System.Data.Odbc. Ricompilare quindi l'applicazione per la versione successiva di .NET Framework.

Se si dispone di un'applicazione sviluppata per .NET Framework versione 2.0 o successiva che effettua la connessione a un'origine dati utilizzando il provider di dati ODBC e si desidera eseguire tale applicazione in .NET Framework versione 1.0, è necessario scaricare il provider di dati ODBC e installarlo nel computer che esegue .NET Framework versione 1.0. Prima di ricompilare l'applicazione per .NET Framework versione 1.0, è inoltre necessario modificare lo spazio dei nomi del provider di dati ODBC in Microsoft.Data.Odbc.

Provider di dati .NET Framework per Oracle

Il provider di dati .NET Framework per Oracle (System.Data.OracleClient) viene fornito con .NET Framework a partire dalla versione 1.1. Gli sviluppatori che utilizzano .NET Framework versione 1.0 possono scaricare il provider di dati Oracle dalla pagina Data Access and Storage del Developer Center (informazioni in lingua inglese).

Se si dispone di un'applicazione sviluppata per .NET Framework versione 2.0 o successiva che effettua la connessione a un'origine dati utilizzando il provider di dati e si desidera eseguire tale applicazione in .NET Framework versione 1.0, è necessario scaricare il provider di dati e installarlo nel computer che esegue .NET Framework versione 1.0.

Sicurezza dall'accesso di codice

I provider di dati .NET Framework utilizzati con .NET Framework versione 1.0 (System.Data.SqlClient e System.Data.OleDb) devono essere eseguiti con autorizzazioni FullTrust. Ogni tentativo di utilizzare i provider di dati .NET Framework con .NET Framework versione 1.0 in un'area con autorizzazioni inferiori a FullTrust genera un'eccezione SecurityException.

A partire da .NET Framework versione 2.0, tutti i provider di dati .NET Framework possono tuttavia essere utilizzati in aree parzialmente attendibili. Inoltre, con .NET Framework versione 1.1 ai provider di dati .NET Framework è stata aggiunta una nuova funzionalità di sicurezza, che consente di definire quali stringhe di connessione possano essere utilizzate in una determinata area di sicurezza. È anche possibile disabilitare l'utilizzo di password vuote per una particolare area di sicurezza. Per ulteriori informazioni, vedere Sicurezza dall'accesso di codice e ADO.NET.

Poiché ogni installazione di .NET Framework dispone di un file Security.config separato, le impostazioni di sicurezza non generano problemi di compatibilità. Tuttavia, se l'applicazione dipende dalle funzionalità di sicurezza aggiuntive di ADO.NET incluse in .NET Framework 1.1 e versioni successive, non sarà possibile distribuirla in un computer che utilizza la versione 1.0.

Esecuzione di SqlCommand

A partire da .NET Framework versione 1.1 è cambiata la modalità di esecuzione di comandi sull'origine dati con il metodo ExecuteReader.

In .NET Framework versione 1.0 il metodo ExecuteReader eseguiva tutti i comandi nel contesto della stored procedure sp_executesql. Di conseguenza, tutti i comandi che incidevano sullo stato della connessione (ad esempio SET NOCOUNT ON) si applicavano solo all'esecuzione del comando corrente. Lo stato della connessione non veniva modificato per i comandi eseguiti successivamente fintanto che la connessione era aperta.

In .NET Framework 1.1 e versioni successive, invece, il metodo ExecuteReader esegue un comando nel contesto della stored sp_executesql solo se il comando contiene parametri, offrendo maggiori vantaggi a livello di prestazioni. Di conseguenza, se un comando che incide sullo stato della connessione viene incluso in un comando senza parametri, le modifiche apportate allo stato della connessione permarranno anche per tutti i comandi eseguiti successivamente, fino alla chiusura della connessione.

Si consideri l'esecuzione del gruppo di comandi seguente in una chiamata al metodo ExecuteReader.

SET NOCOUNT ON;
SELECT * FROM dbo.Customers;

In .NET Framework 1.1 e versioni successive NOCOUNT rimane impostato su ON per tutti i comandi eseguiti successivamente finché la connessione è aperta. In .NET Framework versione 1.0 NOCOUNT è impostato su ON solo durante l'esecuzione del comando corrente.

Tale modifica può incidere sulla compatibilità di un'applicazione con le versioni successive e precedenti, se l'applicazione dipende dal comportamento del metodo ExecuteReader di una delle versioni di .NET Framework.

Per le applicazioni che possono essere eseguite sia sulle versioni successive che sulle versioni precedenti di .NET Framework, è possibile scrivere il codice in modo tale che il comportamento resti invariato indipendentemente dalla versione in cui viene eseguita l'applicazione. Per assicurarsi che un comando modifichi lo stato della connessione per tutti i comandi successivi, si consiglia di eseguire il comando tramite il metodo ExecuteNonQuery. Per assicurarsi che un comando non modifichi lo stato della connessione per tutti i comandi successivi, si consiglia di includervi i comandi che ripristinano lo stato della connessione. Ad esempio:

SET NOCOUNT ON;
SELECT * FROM dbo.Customers;
SET NOCOUNT OFF;

Microsoft SQL Server Native Client

Microsoft SQL Server Native Client include il provider OLE DB SQL e il driver ODBC SQL in un'unica DLL nativa per supportare le applicazioni che utilizzano API del codice nativo (ODBC, OLE DB e ADO) in Microsoft SQL Server. È preferibile utilizzare SQL Server Native Client anziché Microsoft Data Access Components (MDAC) per creare nuove applicazioni o aggiornare applicazioni esistenti in cui si desidera sfruttare le funzionalità introdotte in SQL Server 2005, ad esempio MARS (Multiple Active Result Set), notifiche delle query, tipi definiti dall'utente (UDT) e supporto per il tipo di dati XML.

Microsoft Data Access Components (MDAC)

Con i provider di dati .NET Framework per OLE DB e ODBC è richiesto MDAC 2.6 o versione successiva incluso in tutte le versioni di .NET Framework e si consiglia MDAC 2.8 SP1. Sebbene non sia compromessa da questo requisito, è importante notare che l'esecuzione side-by-side non è attualmente supportata da MDAC. Pertanto, prima di aggiornare i componenti MDAC per la propria installazione, è consigliabile verificare che la propria applicazione continui a funzionare correttamente con la nuova versione.

Per ulteriori informazioni su MDAC, vedere la pagina Web Data Access and Storage del Developer Center (informazioni in lingua inglese)

Windows Data Access Components (Windows DAC)

Windows Data Access Components (Windows DAC) 6.0 è un set di tecnologie incluse in Windows Vista per fornire accesso alle informazioni nell'azienda. Queste tecnologie includono le versioni più recenti delle tecnologie di accesso ai dati incluse in MDAC: Microsoft ActiveX Data Objects (ADO), OLE DB e Microsoft Open Database Connectivity (ODBC).

Per ulteriori informazioni su Windows DAC, vedere Windows Data Access Components SDK Overview (informazioni in lingua inglese).

Vedere anche

Altre risorse

Cenni preliminari su ADO.NET

Recupero e modifica di dati in ADO.NET