Parallele Ausführung in ADO.NET
Aktualisiert: November 2007
Parallele Ausführung in .NET Framework ist die Fähigkeit, eine Anwendung auf einem Computer, auf dem mehrere Versionen von .NET Framework installiert sind, ausschließlich mit der Version auszuführen, für die die Anwendung kompiliert wurde. Ausführliche Informationen zum Konfigurieren der parallelen Ausführung finden Sie unter Parallele Ausführung.
Eine Anwendung, die für die Verwendung einer Version von .NET Framework kompiliert wurde, kann unter einer anderen Version von .NET Framework ausgeführt werden. Es wird jedoch empfohlen, dass Sie für jede installierte Version von .NET Framework eine eigene Version der Anwendung kompilieren und diese separat ausführen. In beiden Szenarien sind die Änderungen zwischen den verschiedenen ADO.NET-Versionen zu berücksichtigen, die die Aufwärts- und Abwärtskompatibilität Ihrer Anwendung beeinträchtigen können.
Aufwärts- und Abwärtskompatibilität
Aufwärtskompatibilität bedeutet, dass eine Anwendung mit einer früheren Version von .NET Framework kompiliert werden kann, ohne dass sich dies negativ auf ihre Ausführbarkeit unter einer späteren Version von .NET Framework auswirkt. Für von .NET Framework 1.1 geschriebener ADO.NET-Code ist aufwärtskompatibel mit neueren Versionen.
Abwärtskompatibilität bedeutet, dass eine Anwendung für eine neuere Version von .NET Framework kompiliert wird, aber ohne Beeinträchtigung der Funktionalität weiterhin auch unter älteren Versionen von .NET Framework ausgeführt werden kann. Dies gilt natürlich nicht für Features, die erst in einer neuen Version von .NET Framework eingeführt wurden.
Der .NET Framework-Datenanbieter für ODBC
Der .NET Framework-Datenanbieter für ODBC (System.Data.Odbc) gehört seit Version 1.1 zum Lieferumfang von .NET Framework. Entwickler, die mit .NET Framework 1.0 arbeiten, können den ODBC-Datenanbieter von der Developer Center-Website Data Access and Storage herunterladen. Der Namespace für den heruntergeladenen .NET Framework-Datenanbieter für ODBC lautet Microsoft.Data.Odbc.
Wenn Sie eine Anwendung haben, die für .NET Framework 1.0 entwickelt wurde und den ODBC-Datenanbieter verwendet, um eine Verbindung mit Ihrer Datenquelle herzustellen, und Sie diese Anwendung unter .NET Framework 1.1 oder höher ausführen möchten, müssen Sie den Namespace für den ODBC-Datenanbieter auf System.Data.Odbc ändern. Anschließend müssen Sie die Anwendung für die neuere Version von .NET Framework neu kompilieren.
Wenn Sie eine für .NET Framework 2.0 oder höher entwickelte Anwendung verwenden, die mithilfe des ODBC-Datenanbieters eine Verbindung zur Datenquelle herstellt, und Sie diese Anwendung mit .NET Framework 1.0 ausführen möchten, müssen Sie den ODBC-Datenanbieter herunterladen und ihn im .NET Framework 1.0-System installieren. Anschließend müssen Sie den Namespace für den ODBC-Datenanbieter in Microsoft.Data.Odbc ändern und die Anwendung für .NET Framework Version 1.0 neu kompilieren.
Der .NET Framework-Datenanbieter für Oracle
Der .NET Framework-Datenanbieter für Oracle (System.Data.OracleClient) gehört seit Version 1.1 zum Lieferumfang von .NET Framework. Entwickler, die mit .NET Framework 1.0 arbeiten, können den Datenanbieter für Oracle von der Developer Center-Website Data Access and Storage herunterladen.
Wenn Sie eine für .NET Framework 2.0 oder höher entwickelte Anwendung verwenden, die mithilfe des Datenanbieters eine Verbindung zur Datenquelle herstellt, und Sie diese Anwendung mit .NET Framework 1.0 ausführen möchten, müssen Sie den Datenanbieter herunterladen und ihn im .NET Framework 1.0-System installieren.
Codezugriffssicherheit
Die .NET Framework-Datenanbieter in .NET Framework 1.0 (System.Data.SqlClient, System.Data.OleDb) müssen mit FullTrust-Berechtigung ausgeführt werden. Jeder Versuch, die .NET Framework-Datenanbieter aus .NET Framework 1.0 in einer Zone mit einer geringeren Berechtigung als FullTrust zu verwenden, löst eine SecurityException aus.
Ab .NET Framework 2.0 können jedoch alle .NET Framework-Datenanbieter in teilweise vertrauenswürdigen Zonen verwendet werden. Außerdem wurde den .NET Framework-Datenanbietern in .NET Framework 1.1 ein neues Sicherheitsfeature hinzugefügt. Mithilfe dieses Features können Sie die Verbindungszeichenfolgen einschränken, die in einer bestimmten Sicherheitszone verwendet werden dürfen. Es kann auch die Verwendung leerer Kennwörter für eine bestimmte Sicherheitszone deaktiviert werden. Weitere Informationen finden Sie unter Codezugriffssicherheit und ADO.NET.
Da jede Installation von .NET Framework über eine eigene Security.config-Datei verfügt, treten bei Sicherheitseinstellungen keine Probleme bezüglich der Kompatibilität auf. Wenn die Anwendung jedoch von den zusätzlichen Sicherheitsfunktionen von ADO.NET in .NET Framework 1.1 oder höher abhängig ist, können Sie sie nicht an ein System mit Version 1.0 verteilen.
"SqlCommand"-Ausführung
Ab .NET Framework 1.1 wurde das Verfahren geändert, mit dem der ExecuteReader Befehle an der Datenquelle ausführt.
In .NET Framework 1.0 hat der ExecuteReader alle Befehle im Kontext der gespeicherten Prozedur sp_executesql ausgeführt. Dadurch gelten Befehle, die den Zustand der Verbindung betreffen (z. B. SET NOCOUNT ON), nur für die Ausführung des aktuellen Befehls. Der Zustand der Verbindung wird bei offener Verbindung für keinen der nachfolgenden ausgeführten Befehle verändert.
In .NET Framework 1.1 und höher führt der ExecuteReader einen Befehl im Kontext der gespeicherten Prozedur sp_executesql nur dann aus, wenn der Befehl Parameter enthält. Dies trägt zu einer höheren Arbeitsgeschwindigkeit bei. Dadurch verändern Befehle, die den Zustand der Verbindung betreffen und die zu einem Befehl ohne Parameter gehören, den Zustand der Verbindung für alle nachfolgenden, bei offener Verbindung ausgeführten Befehle.
Betrachten Sie den folgenden Batch von Befehlen, die in einem Aufruf an ExecuteReader ausgeführt werden.
SET NOCOUNT ON;
SELECT * FROM dbo.Customers;
In .NET Framework 1.1 und höher bleibt NOCOUNT für alle nachfolgenden Befehle, die bei offener Verbindung ausgeführt werden, auf ON festgelegt. In .NET Framework 1.0 ist NOCOUNT nur für die jeweils aktuelle Befehlsausführung auf ON gesetzt.
Diese Änderung kann sowohl die Aufwärts- als auch die Abwärtskompatibilität der Anwendung beeinträchtigen, sofern eine Abhängigkeit vom Verhalten des ExecuteReader für eine der beiden .NET Framework-Versionen besteht.
Bei Anwendungen, die sowohl mit älteren als auch mit neueren Versionen von .NET Framework ausführbar sind, können Sie den Code so schreiben, dass ein identisches Verhalten gewährleistet ist, egal, welche Version verwendet wird. Um sicherzustellen, dass ein Befehl den Zustand der Verbindung für alle nachfolgenden Befehle verändert, wird empfohlen, den Befehl mit ExecuteNonQuery auszuführen. Wenn Sie sicherstellen möchten, dass ein Befehl die Verbindung für alle nachfolgenden Befehle nicht verändert, wird empfohlen, in den Befehl die Befehle zu integrieren, mit denen der Zustand der Verbindung zurückgesetzt wird. Beispiel:
SET NOCOUNT ON;
SELECT * FROM dbo.Customers;
SET NOCOUNT OFF;
Microsoft SQL Server Native Client
Microsoft SQL Server Native Client enthält den SQL-OLE DB-Anbieter und den SQL-ODBC-Treiber. Beide befinden sich in derselben systemeigenen DLL (Dynamic Link Library) und unterstützen Anwendungen, die APIs mit systemeigenem Code (ODBC, OLE DB und ADO) für Microsoft SQL Server verwenden. Zum Erstellen neuer Anwendungen oder Überarbeiten bestehender Anwendungen, die die neuen SQL Server 2005-Features wie MARS (Multiple Active Result Sets), Abfragebenachrichtigungen, benutzerdefinierte Typen (User-Defined Types, UDTs) und XML-Datentypunterstützung verwenden sollen, sollte statt MDAC (Microsoft Data Access Components) SQL Server Native Client verwendet werden.
Microsoft Data Access Components (MDAC)
Die .NET Framework-Datenanbieter für OLE DB und ODBC benötigen in allen Versionen von .NET Framework MDAC 2.6 oder höher. Es wird die Verwendung von MDAC 2.8 SP1 empfohlen. Obwohl diese Anforderung keine Probleme bei der parallelen Ausführung verursacht, muss beachtet werden, dass MDAC derzeit keine parallele Ausführung unterstützt. Bevor die MDAC-Komponenten für die Installation aktualisiert werden, muss daher überprüft werden, dass die Anwendung mit der neuen Version weiterhin korrekt funktioniert.
Weitere Informationen zu MDAC finden Sie auf der Developer Center-Website Data Access and Storage.
Windows Data Access Components (Windows DAC)
Bei Windows Data Access Components (Windows DAC) 6.0 handelt es sich um verschiedene Technologien, die unter Windows Vista zur Verfügung stehen und den Zugriff auf Unternehmensinformationen ermöglichen. Zu diesen Technologien gehören die aktuellen Datenzugrifftechnologien, die in MDAC zur Verfügung stehen: Microsoft ActiveX Data Objects (ADO), OLE DB und Microsoft Open Database Connectivity (ODBC).
Weitere Informationen über Windows DAC finden Sie unter Übersicht über das Windows Data Access Components-SDK.