Parallele Ausführung in ADO.NET
Inhaltsverzeichnis reduzieren
Inhaltsverzeichnis erweitern
Markieren Sie das Kontrollkästchen Englisch, um die englische Version dieses Artikels anzuzeigen. Sie können den englischen Text auch in einem Popup-Fenster einblenden, indem Sie den Mauszeiger über den Text bewegen.
Übersetzung
Englisch

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 in .NET Framework.

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ä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 (System.Data.Odbc) gehört seit Version 1.1 zum Lieferumfang von .NET Framework. Entwickler, die mit .NET Framework Version 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 (System.Data.OracleClient) gehört seit Version 1.1 zum Lieferumfang von .NET Framework. Entwickler, die mit .NET Framework Version 1.0 arbeiten, können den Datenanbieter 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.

Die .NET Framework-Datenanbieter in .NET Framework 1.0 (System.Data.SqlClient, System.Data.OleDb) müssen mit <legacyBold>FullTrust</legacyBold>-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 <legacyBold>Security.config</legacyBold>-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.

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. Zum Beispiel:

SET NOCOUNT ON;
SELECT * FROM dbo.Customers;
SET NOCOUNT OFF;
Anzeigen:
© 2016 Microsoft