Parallele Ausführung und ADO.NET

Artikel
03/31/2008

Parallele Ausführung in .NET Framework bezeichnet die Möglichkeit, eine Anwendung auf einem einzelnen Computer auszuführen, auf dem mehrere Versionen von .NET Framework installiert sind, ohne dass die Anwendung beeinflusst wird. Obwohl auf einem einzelnen Computer mehrere Versionen von .NET Framework zur Verfügung stehen, verwendet die Anwendung also die Version, für die sie kompiliert wurde, und wird von den anderen auf dem Computer installierten .NET Framework-Versionen nicht beeinflusst. Ausführliche Informationen zum Konfigurieren der parallelen Ausführung finden Sie unter Verwenden der parallelen Ausführung.

Eine Anwendung, die mit einer Version von .NET Framework kompiliert wurde, kann mit einer anderen Version von .NET Framework ausgeführt werden. Es wird jedoch empfohlen, für jede installierte Version von .NET Framework eine Version der Anwendung zu kompilieren und diese separat auszuführen. In jedem Szenario sollten Sie die Veränderungen zwischen verschiedenen ADO.NET-Versionen beachten, die die Aufwärts- und Abwärtskompatibilität der Anwendung beeinträchtigen können.

Aufwärts- und Abwärtskompatibilität

Aufwärtskompatibilität bedeutet, dass eine Anwendung sowohl unter neueren als auch unter früheren Versionen von .NET Framework kompiliert und ausgeführt werden kann. Der für .NET Framework, Version 1.1, geschriebene ADO.NET-Code ist aufwärtskompatibel, sofern Sie keine neuen Funktionen verwenden, die in .NET Framework, Version 1.1, eingeführt wurden. Im Folgenden finden Sie die neuen Funktionen, die ADO.NET in .NET Framework, Version 1.1, hinzugefügt wurden:

Die EnlistDistributedTransaction-Methode von Connection. Siehe Eintragen in eine verteilte Transaktion.
Die HasRows-Eigenschaft des DataReader. Siehe Abrufen von Daten mit dem DataReader-Objekt.
Hinzufügung des .NET Framework-Datenproviders für ODBC. Siehe System.Data.Odbc-Namespace.
Hinzufügung des .NET Framework-Datenproviders für Oracle. Siehe System.Data.OracleClient-Namespace.

Abwärtskompatibilität bedeutet, dass eine Anwendung für eine frühere Version von .NET Framework kompiliert wurde und weiterhin in neueren Versionen von .NET Framework ohne Beeinträchtigung der Funktionalität ausgeführt wird.

Obwohl die ADO.NET-Komponenten in .NET Framework, Version 1.1, sowohl als aufwärtskompatibel als auch als abwärtskompatibel (neue Funktionen ausgenommen) entwickelt wurden, müssen Sie einige Faktoren beachten, die die Aufwärts- oder Abwärtskompatibilität einer Anwendung beeinflussen.

Im Folgenden werden Aspekte der parallelen Ausführung beschrieben, die die Abwärts- oder Aufwärtskompatibilität des ADO.NET-Codes beeinträchtigen können. Die hier besprochenen Fragen sind:

Der .NET Framework-Datenprovider für ODBC
Der .NET Framework-Datenprovider für Oracle
Codezugriffssicherheit
Das DataSet
SqlCommand-Ausführung
MDAC-Version

Der .NET Framework-Datenprovider für ODBC

Der .NET Framework-Datenprovider für ODBC (System.Data.Odbc) ist ab Version 1.1 ein Bestandteil von .NET Framework. Der ODBC-Datenprovider ist jedoch nicht in .NET Framework, Version 1.0, enthalten. Der ODBC-Datenprovider steht Entwicklern, die .NET Framework, Version 1.0, verwenden, als Download unter https://msdn.microsoft.com/downloads im Web zur Verfügung. Der Namespace für den gedownloadeten .NET Framework-Datenprovider für ODBC lautet Microsoft.Data.Odbc.

Wenn Sie eine für .NET Framework, Version 1.0, entwickelte Anwendung, die mit dem ODBC-Datenprovider eine Verbindung mit der Datenquelle herstellt, mit .NET Framework, Version 1.1, ausführen möchten, müssen Sie den Namespace für den ODBC-Datenprovider auf System.Data.Odbc aktualisieren. Anschließend müssen Sie sie für .NET Framework, Version 1.1, erneut kompilieren.

Wenn Sie eine für .NET Framework, Version 1.1, entwickelte Anwendung, die mit dem ODBC-Datenprovider eine Verbindung mit der Datenquelle herstellt, unter .NET Framework, Version 1.0, ausführen möchten, müssen Sie den ODBC-Datenprovider downloaden und im .NET Framework-System, Version 1.0, installieren. Dann müssen Sie den Namespace für den ODBC-Datenprovider auf Microsoft.Data.Odbc aktualisieren und eine erneute Kompilierung für .NET Framework, Version 1.0, durchführen.

Der .NET Framework-Datenprovider für Oracle

Der .NET Framework-Datenprovider für Oracle (System.Data.OracleClient) ist ab Version 1.1 ein Bestandteil von .NET Framework. Der Datenprovider ist jedoch nicht in .NET Framework, Version 1.0, enthalten. Der Datenprovider steht Entwicklern, die .NET Framework, Version 1.0, verwenden, als Download unter https://msdn.microsoft.com/downloads im Web zur Verfügung.

Wenn Sie eine für .NET Framework, Version 1.1, entwickelte Anwendung, die mit dem Datenprovider eine Verbindung mit der Datenquelle herstellt, unter .NET Framework, Version 1.0, ausführen möchten, müssen Sie den Datenprovider downloaden und im .NET Framework-System, Version 1.0, installieren.

Codezugriffssicherheit

Die .NET Framework-Datenprovider in .NET Framework, Version 1.0, (System.Data.SqlClient, System.Data.OleDb) müssen mit FullTrust-Berechtigung ausgeführt werden. Jeder Versuch, .NET Framework-Datenprovider aus .NET Framework, Version 1.0, in einer Zone zu verwenden, die nicht über FullTrust-Berechtigung verfügt, führt zu einer SecurityException.

In .NET Framework, Version 1.1, kann der .NET Framework-Datenprovider für SQL Server jetzt in teilweise vertrauenswürdigen Zonen verwendet werden. Für die OLE DB-Datenprovider und die ODBC-Datenprovider ist weiterhin die FullTrust-Berechtigung erforderlich.

Den .NET Framework-Datenprovidern in .NET Framework, Version 1.1, wurde eine neue Sicherheitsfunktion hinzugefügt, mit der Sie die Verbindungszeichenfolgen einschränken können, die in einer bestimmten Sicherheitszone verwendet werden können. Sie können auch die Verwendung von leeren Kennwörtern für eine bestimmte Sicherheitszone deaktivieren. Weitere Informationen finden Sie unter Codezugriffssicherheit und ADO.NET.

Da jede Installation von .NET Framework eine eigene Datei Security.config aufweist (siehe Sicherheitskonfigurationsdateien), treten bei Sicherheitseinstellungen keine Probleme bezüglich der Aufwärts- oder Abwärtskompatibilität auf. Wenn die Anwendung jedoch von den zusätzlichen Sicherheitsfunktionen von ADO.NET in .NET Framework, Version 1.1, abhängig ist, können Sie sie nicht an ein System mit Version 1.0 weitergeben.

Das DataSet

Das DataSet in .NET Framework, Version 1.1, enthält mehrere Lösungen für Programmfehler, die das Verhalten des DataSets im Gegensatz zu dem Verhalten in .NET Framework, Version 1.0, verändern. Wenn der Code von dem Verhalten in Version 1.0 abhängig ist, tritt möglicherweise ein Problem im Zusammenhang mit der Abwärtskompatibilität auf. Folgende Änderungen sind am Verhalten des DataSets vorgenommen worden.

Standardspaltenwerte, die als leere Zeichenfolgen im XSD-Schema (XML Schema Definition Language) für ein DataSet festgelegt wurden, werden nicht mehr als NULL interpretiert.
Einschränkungen werden nach Änderung der Locale-Eigenschaft überprüft.
Wenn das Schema für das DataSet Elemente mit demselben Namen und unterschiedlichen Typen in einem Namespace enthält, löst Version 1.1 eine Ausnahme aus, wenn Sie das Schema in ein DataSet lesen möchten, oder wenn das DataSet zu einem Client der Version 1.1 verschoben wird. Wenn z. B. bei zwei verknüpften Tabellen eine Spalte in der übergeordneten Tabelle denselben Namen wie in der untergeordneten Tabelle hat, wird eine Ausnahme ausgelöst, wenn die Nested-Eigenschaft der DataRelation den Wert true hat, da dies die untergeordnete Tabelle in denselben Namespace platziert wie die übergeordnete Tabelle im XML-Schema für das DataSet. Wenn die Nested-Eigenschaft der DataRelation den Wert false hat, wird keine Ausnahme ausgelöst.
Ein spezieller Fall beim Verschieben eines DataSets liegt dann vor, wenn die AllowDBNull-Eigenschaft einer Spalte auf false und die ColumnMapping-Eigenschaft der Spalte auf MappingType.Attribute festgelegt wird. Wenn ein DataSet aus einem System mit Version 1.0 verschoben wird, tritt eine Ausnahme auf, wenn der Client versucht, das verschobene DataSet zu laden. Bei einem DataSet, das aus einem System mit Version 1.1 verschoben wird, tritt keine Ausnahme auf. Systeme mit Version 1.0 können jedoch den DefaultValue der Spalte nicht lesen. Bei Systemen mit Version 1.0 ist der DefaultValue der Spalte String.Empty.
Wenn zum XML-Schema für das DataSet ein targetNamespace gehört, werden die Daten möglicherweise nicht gelesen. Außerdem können Ausnahmen ausgelöst werden, wenn Sie ReadXml zum Laden des DataSets mit XML aufrufen, das Elemente ohne kennzeichnenden Namespace enthält. Um in diesem Fall nicht gekennzeichnete Elemente lesen zu können, legen Sie im XML-Schema elementFormDefault auf qualified fest. Beispiel:
```
<xsd:schema id="MyDataSet" 
  elementFormDefault="qualified"
  targetNamespace="http://www.tempuri.org/MyDataSet.xsd" 
  xmlns="http://www.tempuri.org/MyDataSet.xsd" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
</xsd:schema>
```

SqlCommand-Ausführung

In .NET Framework, Version 1.1, hat sich das Verhalten von SqlCommand.ExecuteReader beim Ausführen von Befehlen in der Datenquelle geändert.

In .NET Framework, Version 1.0, führt SqlCommand.ExecuteReader alle Befehle im Kontext der gespeicherten Prozedur sp_executesql aus. 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, Version 1.1, führt SqlCommand.ExecuteReader einen Befehl im Kontext der gespeicherten Prozedur sp_executesql nur dann aus, wenn der Befehl Parameter enthält, da dies einen Leistungsvorteil bietet. 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 SqlCommand.ExecuteReader ausgeführt werden.

SET NOCOUNT ON;
SELECT * FROM Customers;

In .NET Framework, Version 1.1, bleibt NOCOUNT für alle nachfolgenden, bei offener Verbindung ausgeführten Befehle auf ON festgelegt. In .NET Framework, Version 1.0, ist NOCOUNT nur für die jeweils aktuelle Befehlsausführung auf ON festgelegt.

Diese Veränderung kann sowohl die Aufwärts- als auch die Abwärtskompatibilität der Anwendung betreffen, wenn Sie das Verhalten von SqlCommand.ExecuteReader für jeder der Versionen von .NET Framework zugrunde legen.

Für Anwendungen, die sowohl mit früheren als auch mit neueren Versionen von .NET Framework ausführbar sind, können Sie durch Schreiben des Codes gewährleisten, dass das Verhalten unabhängig von der verwendeten Version identisch ist. Um sicherzustellen, dass ein Befehl den Zustand der Verbindung für alle nachfolgenden Befehle verändert, wird empfohlen, den Befehl mit SqlCommand.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 Customers;
SET NOCOUNT OFF;

MDAC-Version

Für die .NET Framework-Datenprovider aller Versionen von .NET Framework muss MDAC 2.6 oder höher installiert sein. Obwohl dies keine Probleme bei der parallelen Ausführung aufwirft, müssen Sie beachten, dass MDAC derzeit keine parallele Ausführung unterstützt. Bevor die MDAC-Komponenten für die Installation aktualisiert werden, muss daher unbedingt sichergestellt werden, dass die Anwendung mit der neuen Version weiterhin ordnungsgemäß funktioniert.

Siehe auch

Übersicht über ADO.NET | ADO.NET-Architektur | Datenzugriff mit .NET Framework-Datenprovidern

Freigeben über