Syntax von Verbindungszeichenfolgen
Alle .NET Framework-Datenanbieter besitzen ein Connection-Objekt, das von DbConnection erbt, sowie eine anbieterspezifische ConnectionString-Eigenschaft. Die spezifische Verbindungszeichenfolgensyntax für den jeweiligen Anbieter wird in dessen ConnectionString-Eigenschaft dokumentiert. In der folgenden Tabelle sind die vier Datenanbieter aufgelistet, die in .NET Framework enthalten sind.
| .NET Framework-Datenanbieter | BESCHREIBUNG |
|---|---|
| System.Data.SqlClient | Ermöglicht den Datenzugriff für Microsoft SQL Server. Weitere Informationen zur Verbindungszeichenfolgensyntax finden Sie unter ConnectionString. |
| System.Data.OleDb | Ermöglicht den Datenzugriff für Datenquellen, die mit OLE DB verfügbar gemacht werden. Weitere Informationen zur Verbindungszeichenfolgensyntax finden Sie unter ConnectionString. |
| System.Data.Odbc | Ermöglicht den Datenzugriff für Datenquellen, die mit ODBC verfügbar gemacht werden. Weitere Informationen zur Verbindungszeichenfolgensyntax finden Sie unter ConnectionString. |
| System.Data.OracleClient | Ermöglicht den Datenzugriff für Oracle 8.1.7 oder höher. Weitere Informationen zur Verbindungszeichenfolgensyntax finden Sie unter ConnectionString. |
Verbindungszeichenfolgen-Generatoren
In ADO.NET 2.0 wurden die folgenden Verbindungszeichenfolgen-Generatoren für .NET Framework-Datenanbieter eingeführt.
- SqlConnectionStringBuilder
- OleDbConnectionStringBuilder
- OdbcConnectionStringBuilder
- OracleConnectionStringBuilder
Mit den Verbindungszeichenfolgen-Generatoren können Sie zur Laufzeit syntaktisch gültige Verbindungszeichenfolgen erstellen, sodass Sie die Werte der Verbindungszeichenfolgen nicht manuell im Code verketten müssen. Weitere Informationen finden Sie in Connection String Builders (Verbindungszeichenfolgengeneratoren).
Windows-Authentifizierung
Die Windows-Authentifizierung (mitunter als integrierte Sicherheit bezeichnet) kann zum Herstellen einer Verbindung mit Datenquellen, die diese unterstützen, verwendet werden. Die in der Verbindungszeichenfolge zu verwendende Syntax richtet sich nach dem Datenanbieter. In der folgenden Tabelle wird die Syntax der Windows-Authentifizierung dargestellt, die bei .NET Framework-Datenanbietern verwendet wird.
| Anbieter | Syntax |
|---|---|
SqlClient |
Integrated Security=true;-- or --Integrated Security=SSPI; |
OleDb |
Integrated Security=SSPI; |
Odbc |
Trusted_Connection=yes; |
OracleClient |
Integrated Security=yes; |
Hinweis
Wenn der Integrated Security=true-Anbieter verwendet wird, wird bei OleDb eine Ausnahme ausgelöst.
Wichtig
Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Wenn Sie eine Verbindung mit Azure SQL herstellen, ist Managed Identities for Azure Resources die empfohlene Authentifizierungsmethode.
SqlClient-Verbindungszeichenfolgen
Die Syntax für eine SqlConnection-Verbindungszeichenfolge wird in der SqlConnection.ConnectionString-Eigenschaft dokumentiert. Mit der ConnectionString-Eigenschaft können Sie eine Verbindungszeichenfolge für eine SQL Server-Datenbank abrufen oder festlegen. Wenn Sie eine Verbindung mit einer früheren Version von SQL Server herstellen müssen, müssen Sie den .NET Framework-Datenanbieter für OLE DB verwenden (System.Data.OleDb). Für die meisten Schlüsselwörter in Verbindungszeichenfolgen gibt es bei den SqlConnectionStringBuilder-Eigenschaften passende Entsprechungen.
Wichtig
Die Standardeinstellung für das Schlüsselwort Persist Security Info ist false. Wenn die Einstellung in true bzw. yes geändert wird, sind sicherheitsrelevante Informationen, die über diese Verbindung übertragen werden, wie Benutzer-ID und Kennwort, nicht mehr sicher. Lassen Sie Persist Security Info auf false festgelegt, um sicherzustellen, dass eine nicht vertrauenswürdige Quelle keinen Zugriff auf sensible Informationen in Verbindungszeichenfolgen hat.
Windows-Authentifizierung mit SqlClient
Alle folgenden Syntaxformen verwenden beim Herstellen einer Verbindung mit der Datenbank AdventureWorks auf einem lokalen Server die Windows-Authentifizierung.
"Persist Security Info=False;Integrated Security=true;
Initial Catalog=AdventureWorks;Server=MSSQL1"
"Persist Security Info=False;Integrated Security=SSPI;
database=AdventureWorks;server=(local)"
"Persist Security Info=False;Trusted_Connection=True;
database=AdventureWorks;server=(local)"
Wichtig
Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Wenn Sie eine Verbindung mit Azure SQL herstellen, ist Managed Identities for Azure Resources die empfohlene Authentifizierungsmethode.
SQL Server-Authentifizierung mit SqlClient
Zum Herstellen einer Verbindung mit SQL Server (lokal) ist vorzugsweise die Windows-Authentifizierung zu verwenden. Wenn jedoch die SQL Server-Authentifizierung erforderlich ist, verwenden Sie zum Angeben eines Benutzernamens und Kennworts die im Folgenden beschriebene Syntax. In diesem Beispiel werden der Benutzername und das Kennwort durch Sternchen dargestellt.
"Persist Security Info=False;User ID=*****;Password=*****;Initial Catalog=AdventureWorks;Server=MySqlServer"
Wenn Sie eine Verbindung mit Azure SQL-Datenbank oder Azure SQL Data Warehouse herstellen und eine Anmeldung im Format user@servername anbieten, stellen Sie sicher, dass der Wert servername in der Anmeldung mit dem für Server= angegebenen Wert übereinstimmt.
Hinweis
Das Angeben der Windows-Authentifizierung hat Vorrang vor SQL Server-Anmeldungen. Wenn Sie Integrated Security=true und einen Benutzernamen und ein Kennwort angeben, werden der Benutzername und das Kennwort ignoriert, und die Windows-Authentifizierung wird verwendet.
Wichtig
Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Wenn Sie eine Verbindung mit Azure SQL herstellen, ist Managed Identities for Azure Resources die empfohlene Authentifizierungsmethode.
Herstellen einer Verbindung mit einer benannten Instanz von SQL Server
Wenn Sie eine Verbindung mit einer benannten Instanz von SQL Server herstellen möchten, verwenden Sie die Syntax Servername\Instanzname.
"Data Source=MySqlServer\\MSSQL1;"
Sie können beim Erstellen einer Verbindungszeichenfolge auch die DataSource-Eigenschaft von SqlConnectionStringBuilder auf den Instanznamen festlegen. Die DataSource-Eigenschaft eines SqlConnection-Objekts ist schreibgeschützt.
Eingeben von Änderungen der Systemversion
Das Schlüsselwort Type System Version in SqlConnection.ConnectionString gibt die clientseitige Darstellung von SQL Server-Typen an. Weitere Informationen zum SqlConnection.ConnectionString-Schlüsselwort finden Sie unter Type System Version.
Herstellen einer Verbindung und Anfügen an SQL Server Express-Benutzerinstanzen
Benutzerinstanzen sind eine Funktion in SQL Server Express. Mit ihrer Hilfe können Benutzer, die mit einem lokalen Windows-Konto der untersten Berechtigungsebene (LUA) arbeiten, eine SQL Server-Datenbank anfügen und ausführen, ohne dass dafür Administratorrechte erforderlich sind. Eine Benutzerinstanz wird mit den Windows-Anmeldeinformationen des Benutzers und nicht als Dienst ausgeführt.
Weitere Informationen zum Arbeiten mit Benutzerinstanzen finden Sie unter SQL Server Express-Benutzerinstanzen.
Verwenden von TrustServerCertificate
Das Schlüsselwort TrustServerCertificate ist nur gültig, wenn unter Verwendung eines gültigen Zertifikats eine Verbindung mit einer SQL Server-Instanz hergestellt wird. Wenn TrustServerCertificate auf true gesetzt wird, verwendet die Transportschicht zum Verschlüsseln des Kanals SSL und umgeht beim Validieren der Vertrauenswürdigkeit die Zertifikatkette.
"TrustServerCertificate=true;"
Hinweis
Wenn TrustServerCertificate auf true gesetzt wird und die Verschlüsselung aktiviert ist, wird die auf dem Server angegebene Verschlüsselungsstufe auch dann verwendet, wenn Encrypt in der Verbindungszeichenfolge auf false gesetzt ist. Andernfalls schlägt die Verbindung fehl.
Aktivieren der Verschlüsselung
Wenn auf dem Server kein Zertifikat bereitgestellt wurde und Sie die Verschlüsselung aktivieren möchten, müssen Sie im SQL Server-Konfigurations-Manager die Optionen Protokollverschlüsselung erzwingen und Dem Serverzertifikat vertrauen aktivieren. In diesem Fall wird bei der Verschlüsselung ein selbstsigniertes Serverzertifikat ohne Überprüfung verwendet, wenn kein überprüfbares Zertifikat auf dem Server bereitgestellt wurde.
Die Anwendungseinstellungen können nicht zu einer Einschränkung der in SQL Server konfigurierten Sicherheitsstufe führen, sondern verstärken sie sogar möglicherweise. Eine Anwendung kann die Verschlüsselung anfordern, indem die Schlüsselwörter TrustServerCertificate und Encrypt auf true festgelegt werden. Dadurch wird sichergestellt, dass die Verschlüsselung auch dann erfolgt, wenn kein Serverzertifikat bereitgestellt wurde und die Option Protokollverschlüsselung erzwingen für den Client nicht konfiguriert wurde. Wenn jedoch TrustServerCertificate in der Clientkonfiguration nicht aktiviert wird, ist immer noch ein bereitgestelltes Serverzertifikat erforderlich.
In der folgenden Tabelle werden alle Fälle beschrieben.
| Protokollverschlüsselung erzwingen - Clienteinstellung | Dem Serverzertifikat vertrauen | Verbindungszeichenfolge/Attribut "Encrypt"/"Use Encryption for Data" | Verbindungszeichenfolge/Attribut "TrustServerCertificate" | Ergebnis |
|---|---|---|---|---|
| Nein | N/V | Nein (Standard) | Wird ignoriert. | Keine Verschlüsselung. |
| Nein | N/V | Ja | Nein (Standard) | Eine Verschlüsselung findet nur statt, wenn ein überprüfbares Serverzertifikat vorliegt, anderenfalls schlägt der Verbindungsversuch fehl. |
| Nein | N/V | Ja | Ja | Verschlüsselung wird immer durchgeführt, es wird jedoch z. B. ein selbstsigniertes Serverzertifikat verwendet. |
| Ja | Nein | Wird ignoriert. | Wird ignoriert. | Die Verschlüsselung erfolgt nur, wenn ein überprüfbares Serverzertifikat vorhanden ist. Andernfalls schlägt der Verbindungsversuch fehl. |
| Ja | Ja | Nein (Standard) | Wird ignoriert. | Verschlüsselung wird immer durchgeführt, es wird jedoch z. B. ein selbstsigniertes Serverzertifikat verwendet. |
| Ja | Ja | Ja | Nein (Standard) | Die Verschlüsselung erfolgt nur, wenn ein überprüfbares Serverzertifikat vorhanden ist. Andernfalls schlägt der Verbindungsversuch fehl. |
| Ja | Ja | Ja | Ja | Verschlüsselung wird immer durchgeführt, es wird jedoch z. B. ein selbstsigniertes Serverzertifikat verwendet. |
Weitere Informationen finden Sie unter Verwenden von Verschlüsselung ohne Überprüfung.
OleDb-Verbindungszeichenfolgen
Mit der ConnectionString-Eigenschaft von OleDbConnection können Sie eine Verbindungszeichenfolge für eine OLE DB-Datenquelle wie Microsoft Access abrufen bzw. festlegen. Sie können auch zur Laufzeit mit der OleDb-Klasse eine OleDbConnectionStringBuilder-Verbindungszeichenfolge erstellen.
Syntax für OleDb-Verbindungszeichenfolgen
Sie müssen für eine OleDbConnection-Verbindungszeichenfolge einen Anbieternamen angeben. Die folgende Verbindungszeichenfolge stellt mithilfe des Jet-Anbieters eine Verbindung mit einer Microsoft Access-Datenbank her. Beachten Sie, dass die Schlüsselwörter User ID und Password optional sind, wenn die Datenbank ungesichert (Standardeinstellung) ist.
Provider=Microsoft.Jet.OLEDB.4.0; Data Source=d:\Northwind.mdb;User ID=Admin;Password=;
Wenn die Jet-Datenbank auf Benutzerebene gesichert ist, müssen Sie den Speicherort der Arbeitsgruppen-Informationsdatei (MDW) angeben. Mit der Arbeitsgruppen-Informationsdatei werden die Anmeldeinformationen in der Verbindungszeichenfolge validiert.
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=d:\Northwind.mdb;Jet OLEDB:System Database=d:\NorthwindSystem.mdw;User ID=*****;Password=*****;
Wichtig
Sie können Verbindungsinformationen für eine OleDbConnection in einer UDL-Datei (Universal Data Link) bereitstellen, davon wird jedoch abgeraten. UDL-Dateien sind nicht verschlüsselt und machen Informationen zur Verbindungszeichenfolge im Klartext verfügbar. Da es sich bei einer UDL-Datei um eine externe Ressource der Anwendung handelt, kann sie nicht mit .NET Framework gesichert werden. UDL-Dateien werden für SqlClient nicht unterstützt.
Wichtig
Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Wenn Sie eine Verbindung mit Azure SQL herstellen, ist Managed Identities for Azure Resources die empfohlene Authentifizierungsmethode.
Verwenden von DataDirectory zum Herstellen einer Verbindung mit Access/Jet
DataDirectory steht nicht exklusiv für SqlClient zur Verfügung. Es kann auch für den System.Data.OleDb- und den System.Data.Odbc-.NET-Datenanbieter verwendet werden. Die folgende OleDbConnection-Beispielzeichenfolge zeigt die Syntax, die erforderlich ist, um eine Verbindung mit der im Anwendungsordner app_data befindlichen Datei Northwind.mdb herzustellen. Die Systemdatenbank (System.mdw) ist ebenfalls an diesem Speicherort gespeichert.
"Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=|DataDirectory|\Northwind.mdb;
Jet OLEDB:System Database=|DataDirectory|\System.mdw;"
Wichtig
Die Angabe des Speicherorts der Systemdatenbank in der Verbindungszeichenfolge ist nicht erforderlich, wenn die Access-/Jet-Datenbank ungesichert ist. Die Sicherheit ist standardmäßig deaktiviert, sodass alle Benutzer eine Verbindung als integrierter Admin-Benutzer mit einem leeren Kennwort herstellen. Selbst wenn die Sicherheit auf Benutzerebene ordnungsgemäß implementiert ist, bleibt eine Jet-Datenbank durch Angriffe verwundbar. Aufgrund der inhärenten Schwäche des dateibasierten Sicherheitsschemas von Access-/Jet-Datenbanken wird davon abgeraten, in solchen Datenbanken sicherheitsrelevante Informationen zu speichern.
Mit Excel verbinden
Für die Verbindung mit einer Excel-Arbeitsmappe wird der Microsoft Jet-Anbieter verwendet. In der folgenden Verbindungszeichenfolge werden mit dem Schlüsselwort Extended Properties Excel-spezifische Eigenschaften festgelegt. HDR=Yes; gibt an, dass die erste Zeile Spaltennamen und keine Daten enthält, und IMEX=1; weist den Treiber an, miteinander vermischte Datenspalten immer als Text zu lesen.
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\MyExcel.xls;Extended Properties=""Excel 8.0;HDR=Yes;IMEX=1""
Beachten Sie, dass die für das Extended Properties-Schlüsselwort erforderlichen doppelten Anführungszeichen ihrerseits ebenfalls in doppelte Anführungszeichen gesetzt werden müssen.
Syntax für Verbindungszeichenfolgen für den Data Shape-Anbieter
Verwenden Sie für den MS Data Shape-Anbieter die Schlüsselwörter Provider und Data Provider. Im folgenden Beispiel wird mithilfe des Shape-Anbieters eine Verbindung mit einer lokalen Instanz von SQL Server hergestellt.
"Provider=MSDataShape;Data Provider=SQLOLEDB;Data Source=(local);Initial Catalog=pubs;Integrated Security=SSPI;"
Wichtig
Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Wenn Sie eine Verbindung mit Azure SQL herstellen, ist Managed Identities for Azure Resources die empfohlene Authentifizierungsmethode.
Odbc-Verbindungszeichenfolgen
Mit der ConnectionString-Eigenschaft einer OdbcConnection können Sie eine Verbindungszeichenfolge für eine OLE DB-Datenquelle abrufen oder festlegen. ODBC-Verbindungszeichenfolgen werden auch vom OdbcConnectionStringBuilder unterstützt.
In der folgenden Verbindungszeichenfolge wird der Microsoft-Texttreiber verwendet.
Driver={Microsoft Text Driver (*.txt; *.csv)};DBQ=d:\bin
Oracle-Verbindungszeichenfolgen
Mit der ConnectionString-Eigenschaft einer OracleConnection können Sie eine Verbindungszeichenfolge für eine OLE DB-Datenquelle abrufen oder festlegen. Oracle-Verbindungszeichenfolgen werden auch vom OracleConnectionStringBuilder unterstützt.
Data Source=Oracle9i;User ID=*****;Password=*****;
Weitere Informationen zur Syntax für ODBC-Verbindungszeichenfolgen finden Sie unter ConnectionString.
Wichtig
Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden. Wenn Sie eine Verbindung mit Azure SQL herstellen, ist Managed Identities for Azure Resources die empfohlene Authentifizierungsmethode.