Share via


Parallele Ausführung in ADO.NET

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 Szenarios 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. Der für .NET Framework 1.1 geschriebene ADO.NET-Code ist aufwärtskompatibel mit höheren 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 Funktionen, 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 haben, die zum Herstellen einer Verbindung mit Ihrer Datenquelle den ODBC-Datenanbieter verwendet, und Sie diese Anwendung mit .NET Framework 1.0 ausführen möchten, müssen Sie den ODBC-Datenanbieter herunterladen und ihn auf dem .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 haben, die zum Herstellen einer Verbindung mit Ihrer Datenquelle den Datenanbieter für Oracle verwendet, und Sie diese Anwendung mit .NET Framework 1.0 ausführen möchten, müssen Sie den Oracle-Datenanbieter herunterladen und ihn auf dem .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 eine neue Sicherheitsfunktion hinzugefügt. Mithilfe dieser Funktion 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 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 neu eingeführten Funktionen in SQL Server 2005, wie MARS (Multiple Active Result Sets), Abfragebenachrichtigungen, benutzerdefinierte Typen (User-Defined Types, UDTs) und XML-Datentypunterstützung, nutzen sollen, sollte statt MDAC (Microsoft Data Access Components) der SQL 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 dies keine Probleme bei der parallelen Ausführung aufwirft, 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)

Windows Data Access Components (Windows-DAC) 6.0 bezeichnet verschiedene Technologien in Windows Vista, mit denen der unternehmensweite Zugriff auf Informationen ermöglicht werden soll. Zu diesen Technologien zählen die letzten Versionen Datenzugriffstechnologien in MDAC, z. B. Microsoft ActiveX Data Objects (ADO), OLE DB und Microsoft Open Database Connectivity (ODBC).

Weitere Informationen zu Windows-DAC finden Sie unter Windows Data Access Components SDK Overview.

Siehe auch

Weitere Ressourcen

Übersicht über ADO.NET

Abrufen und Ändern von Daten in ADO.NET