{"id":55000024,"date":"2016-02-01T00:00:00","date_gmt":"2020-03-27T19:17:30","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=24"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Datenzugriff_mit_ADONET_Teil_2","status":"publish","type":"post","link":"https:\/\/vbentwickler.de\/Datenzugriff_mit_ADONET_Teil_2\/","title":{"rendered":"Datenzugriff mit ADO.NET, Teil 2"},"content":{"rendered":"

Im ersten Teil unserer Artikelreihe zum Thema ADO.NET haben wir uns angesehen, wie Sie mit dem DataReader-Objekt auf die Daten einer Tabelle zugreifen und wie Sie mit dem Command-Objekt Aktionsabfragen durchführen können. Im vorliegenden Teil sehen wir uns an, wie Sie mit dem DataAdapter-Objekt auf die Daten einer Datenbank zugreifen und das DataSet- und das DataTable-Objekt einsetzen, um verbindungslos mit den Daten einer Datenbank zu arbeiten.<\/b><\/p>\n

Die im ersten Teil dieser Artikelreihe vorgestellten Techniken für den Zugriff auf die Daten einer Datenbank erforderten eine geöffnete Verbindung. So etwas ist in einer Desktopdatenbank etwa auf Basis von Microsoft Access kein Problem. Etwas kritischer wird es schon, wenn Sie Access in einer Mehrbenutzerumgebung einsetzen – und vor allem dann, wenn die Anwendung über das Internet über die anzuzeigenden oder zu bearbeitenden Daten zugreift. In Zeiten der Mehrbenutzer-, Internet- und mobilen Anwendungen benötigen wir daher verbindungslose Zugriffstechnologien.<\/p>\n

Die unterstützt ADO.NET durch einige weitere Objekte, welche nach Wunsch mit den Daten einer oder mehrerer Tabellen oder Abfragen der Datenbank gefüllt werden. Der Benutzer zeigt die Daten an, löscht, bearbeitet oder erweitert sie und stößt dann den Speichervorgang für die Daten an. Daraufhin wird erneut eine Verbindung geöffnet und die geänderten Daten werden zurück in die Datenbank geschrieben. Wie dies gelingt, schauen wir uns weiter unten an. Vorher jedoch noch einige Ergänzungen zum ersten Teil dieser Artikelreihe.<\/p>\n

Verbindungszeichenfolge einfach festlegen<\/h2>\n

Wer sich mit dem Zusammenstellen der Zeichenkette für die Verbindungszeichenfolge schwer tut und\/oder Eingabefehler bei der Benennung der Parameter vermeiden will, kann auch ein Objekt namens ConnectionStringBuilder <\/b>verwenden. Dieses gibt es ebenso wie die Objekte Connection<\/b>, Command <\/b>et cetera jeweils mit entsprechendem Präfix für die verschiedenen ADO.NET-Klassen wie System.Data.OLEDB<\/b>, System.Data.ODBC<\/b>, System.Data.SQL <\/b>und so weiter. Da wir aktuell noch eine Access-Datenbank als Datenquelle für unsere Beispiele nutzen, heißt die entsprechende Klasse also OLEDBConnectionStringBuilder<\/b>. Die folgende Prozedur erstellt ein neues Objekt auf Basis dieser Klasse und speichert es in der Variablen ConnectionStringBuilder<\/b>. Die Objektvariable stellt alle für die aktuelle Verbindung möglichen Parameter als Eigenschaften zur Verfügung, sodass Sie die gewünschten Elemente einfach per IntelliSense auswählen wollen.<\/p>\n

Im vorliegenden Fall weisen wir so den Parameter DataSource <\/b>und den Parameter Provider <\/b>zum Objekt ConnectionStringBuilder <\/b>hinzu und stellen so die Verbindungszeichenfolge zusammen, die wir dann über die Eigenschaft ConnectionString <\/b>abfragen und beim Erstellen des OLEDBConnection<\/b>-Objekts verwenden können:<\/p>\n

public static void ConnectionstringBuilder() {\r\n     OleDbConnectionStringBuilder ConnectionStringBuilder = \r\n         new OleDbConnectionStringBuilder();\r\n     ConnectionStringBuilder.DataSource = \"Suedsturm.mdb\";\r\n     ConnectionStringBuilder.Provider = \r\n         \"Microsoft.Jet.OLEDB.4.0\";\r\n     OleDbConnection cnn = new OleDbConnection(\r\n         ConnectionStringBuilder.ConnectionString);\r\n     try {\r\n         cnn.Open();\r\n         Console.WriteLine(\"Provider: {0}\", cnn.Provider);\r\n         Console.WriteLine(\"DataSource: {0}\", \r\n             cnn.DataSource);\r\n         Console.ReadLine();\r\n         cnn.Close();\r\n     }\r\n     catch(Exception e) {\r\n         Console.WriteLine(\"Fehler: {0}\", e.Message);\r\n         Console.ReadLine();\r\n     }\r\n}<\/pre>\n
Im Folgenden haben wir die Ausgabe einiger Eigenschaften des Connection<\/b>-Objekts in eine rudimentäre Fehlerbehandlung gesteckt. Diese greift, wenn innerhalb des try<\/b>-Blocks ein Fehler auftritt. Dann wird der catch<\/b>-Block ausgelöst, der eine Fehlermeldung in der Konsole ausgibt. Mehr zum Thema Fehlerbehandlung lesen Sie im Artikel Fehlerbehandlung mit C#<\/b>.<\/p>\n
Verbindungszeichenfolge speichern<\/h2>\n
Wenn Sie unter Access eine Backend-Datenbank verwenden, wird der Pfad zu den verknüpften Tabellen in der Systemtabelle MSysObjects <\/b>gespeichert. Sollten die verknüpften Tabellen nicht an der vorgesehen Stelle verfügbar sein, löst dies einen Fehler aus. Dies fängt man unter Access ab, indem man beim Öffnen der Datenbank prüft, ob die verknüpfte Datenbank sich am vorgesehenen Ort befindet. Falls nicht, blendet man einen Dialog ein, der dem Benutzer die Auswahl des neuen Speicherorts der Backend-Datenbank ermöglicht und verknüpft die Tabellen dann erneut.<\/p>\n
Dieses Verhalten wollen wir unter C# für Desktop-Anwendungen ähnlich abbilden – zumindest so, dass es für den Benutzer so aussieht. Intern läuft es natürlich etwas anders: Es gibt ja keine Verknüpfung zu einer Datenbank, sondern wir verwenden eine Zeichenkette, welche den Speicherort der zu nutzenden Datenbank angibt. Zumindest in den bisherigen Beispielen (und der Einfachheit halber auch in den meisten weiteren) legen wir die Datenbank direkt im Verzeichnis der .exe<\/b>-Datei ab. Spätestens, wenn Sie einmal eine Anwendung für den Mehrbenutzerbetrieb auslegen und dabei eine Datei wie eine Access-Datenbank, aber möglicherweise auch eine Excel- oder XML-Datei als Datenquelle nutzen, sollten Sie eine Möglichkeit vorsehen, das Vorhandensein der Quelldatei zu prüfen und gegebenenfalls den Speicherort der Datei neu zu ermitteln.<\/p>\n
Hierzu besteht die erste Aufgabe darin, den Pfad zur Quelldatei an einem Ort zu speichern, der außerhalb der kompilierten Anwendung liegt. Anderenfalls müssten Sie die Anwendung ja jedes Mal neu kompilieren, wenn sich der Pfad ändert. Das können Sie bei selbst genutzten Anwendungen tun, aber sicher nicht bei solchen Anwendungen, die Sie an Kunden oder andere Benutzer weitergeben.<\/p>\n
Unter Access hätten wir für einen solchen Zweck einfach eine lokale Optionentabelle verwendet oder alternativ eine Textdatei. Eine C#-Desktop-Anwendung jedoch enthält ja keine eigenen Tabellen zum Speichern von Daten, also müssen wir schon auf eine Art Konfigurationsdatei zurückgreifen. Es gibt jedoch gute Nachrichten: C# sieht für Desktop-Anwendungen eine Möglichkeit vor, Konfigurationsdateien zu pflegen und die enthaltenen Daten einfach per Code einzulesen und auch zu ändern.<\/p>\n
Wie Sie die Verbindungszeichenfolge in einer Konfigurationsdatei speichern, erfahren Sie im Artikel Anwendungskonfigurationsdateien<\/b>.<\/p>\n
Der DataAdapter<\/h2>\n
Genau wie die übrigen ADO.NET-Objekte gibt es auch den DataAdapter <\/b>wieder in verschiedenen Klassen. Dementsprechend heißt der DataAdapter <\/b>beispielsweise SqlDataAdapter<\/b>, OdbcDataAdapter <\/b>oder OleDbDataAdapter<\/b> – je nachdem, mit welcher Klasse Sie auf welchen Datenbanktyp zugreifen möchten.<\/p>\n
Wir beschäftigen uns der Einfachheit halber immer noch mit unserer Access-Beispieldatenbank Suedsturm.mdb<\/b>, also nutzen wir den OleDbDataAdapter<\/b>. Im Folgenden reden wir jedoch neutral von DataAdapter<\/b>, nur im Beispielcode finden Sie entsprechend die Objektbezeichnung OleDbDataAdapter<\/b>.<\/p>\n
Was bietet uns der DataAdapter<\/b> Mit dem Command<\/b>– und dem DataReader<\/b>-Objekt konnten wir ja immerhin schon einmal Auswahlabfragen ausführen und die Ergebnisse vorwärts durchlaufen oder Aktionsabfragen anstoßen. Der DataReader <\/b>erlaubt es aber beispielsweise nicht, einen der enthaltenen Datensätze zu ändern und die geänderte Version zurück in die zugrunde liegenden Tabellen zu schreiben. Genauso wenig, wie Sie damit durch die Datensätze navigieren können – es geht nur vorwärts.<\/p>\n
Außerdem sind Command <\/b>und DataReader <\/b>Objekte, die eine Verbindung zur Datenbank benötigen. Gerade dies ist natürlich für Web-Anwendungen oder Anwendungen auf mobilen Endgeräten nicht sinnvoll, und auch für Desktop-Anwendungen in Mehrbenutzerumgebungen können nicht endlos viele Verbindungen gleichzeitig offen gehalten werden. Daher sieht ADO.NET einige Objekte vor, mit denen Sie die Daten aus der Datenbank einlesen, bearbeiten und wieder zurückschreiben können. Dabei ist nur für das Einlesen und das Zurückschreiben eine Verbindung nötig, zwischendurch wird die Verbindung getrennt.<\/p>\n
Und hier kommt der DataAdapter <\/b>ins Spiel (je nach Anwendungsfall als SqlDataAdapter<\/b>, OdbcDataAdapter<\/b>, OleDbDataAdapter <\/b>et cetera): Er stellt die Verbindung zwischen Client und Server her, um die benötigten Daten aus den Tabellen der Datenbank in lokale Objekte zu übertragen und diese nach Änderungen wieder zurückzuschicken. Dabei stellt der DataAdapter <\/b>nur Verbindungen zum Server her, wenn tatsächlich Daten bewegt werden müssen.<\/p>\n
Connection- und Command-Objekte<\/h2>\n
Die beiden Objekte Connection <\/b>und Command<\/b>, die Sie bereits kennen gelernt haben, dürfen Sie jedoch nicht aus Ihrem Gedächtnis streichen: Das Connection<\/b>-Objekte benötigen wir nämlich nach wie vor, auch um die Verbindungen des DataAdapters <\/b>herzustellen.<\/p>\n
Und das Command<\/b>-Objekt ist immer noch gefragt, wenn es darum geht, Änderungen an den Daten einer Tabelle vorzunehmen, für die wir die vorhandenen Daten nicht erst einlesen und analysieren müssen. Eine Aktionsabfrage etwa zum Anfügen eines neuen Datensatzes oder zum Löschen oder Bearbeiten vorhandener Datensätze ist per Command<\/b>-Objekt immer noch schneller, als wenn Sie die entsprechenden Tabellen über den DataAdapter <\/b>in weitere Objekte laden, die Daten dort ändern und die Änderungen dann zurückschreiben.<\/p>\n
DataTable und DataRow<\/h2>\n
Um mit den über den DataAdapter <\/b>gewonnenen Daten zu arbeiten und etwa in einer Schleife alle Datensätze zu durchlaufen und anzuzeigen, benötigen Sie noch entsprechende Objekte, um diese zu speichern. Das DataTable<\/b>-Objekt nimmt dabei das Ergebnis einer Tabelle oder Abfrage auf. Seine Rows<\/b>-Eigenschaft erlaubt den Zugriff auf die einzelnen Datensätze. Diese können Sie wiederum mit dem DataRow<\/b>-Objekt referenzieren, um gezielt auf die Inhalte zuzugreifen.<\/p>\n
Im Gegensatz zu den Objekten Connection<\/b>, Command <\/b>und DataReader<\/b>, die ja je nach Anforderung etwa aus einem der Namespaces System.Data.Sql<\/b>, System.Data.Odbc <\/b>oder System.Data.OleDb <\/b>stammen, kommen die beiden Objekte DataTable <\/b>und DataRow <\/b>aus dem Namespace System.Data<\/b>. Diesen fügen Sie also noch über folgende Anweisung zur Klasse hinzu:<\/p>\n
using System.Data;<\/pre>\n
DataTable füllen und durchlaufen<\/h2>\n
Damit kommen wir nun endlich zum ersten handfesten Beispiel dieses Artikels. Dabei wollen wir ein DataTable<\/b>-Objekt über einen DataAdapter <\/b>mit den Daten einer Tabelle füllen und die Datensätze durchlaufen und in der Konsole ausgeben (siehe Listing 1).<\/p>\n
public static void DataTableFuellen() {\r\n     string strConnection = \"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=Suedsturm.mdb\";\r\n     string strSQL = \"SELECT * FROM tblKategorien\";\r\n     OleDbConnection cnn = new OleDbConnection(strConnection);\r\n     OleDbDataAdapter da = new OleDbDataAdapter(strSQL, cnn);\r\n     DataTable dt = new DataTable();\r\n     da.Fill(dt);\r\n     for (int i = 0; i < dt.Rows.Count; i++) {\r\n         DataRow row = dt.Rows[i];\r\n         Console.WriteLine(\"{0} {1}\", row[0], row);\r\n     }\r\n     Console.ReadLine();\r\n}<\/pre>\n
Listing 1: Füllen und Durchlaufen einer Tabelle per DataTable<\/span><\/b><\/p>\n
Die Methode speichert zunächst die Verbindungszeichenfolge und die SQL-Abfrage in den beiden Variablen strConnection <\/b>und strSQL<\/b>.<\/p>\n
Dann erzeugt sie ein neues Objekt des Typs OleDbConnection <\/b>und übergibt dabei gleich die zu verwendende Verbindungszeichenfolge, mit der in diesem Beispiel auf die Access-Datenbank Suedsturm.mdb <\/b>im Verzeichnis der C#-Anwendung selbst zugegriffen werden soll.<\/p>\n
Den OleDbDataAdapter <\/b>speichert die Methode nach dem Erstellen und der Übergabe der SQL-Anweisung mit strSQL <\/b>und dem Connection<\/b>-Objekt in der Variablen da<\/b>.<\/p>\n
Hier fällt auf, dass die Methode die Verbindung nicht explizit öffnet, indem Sie die <b>Open<\/b>-Methode aufruft. Dies ist nicht nötig, da die <b>Fill<\/b>-Methode des <b>DataAdapter<\/b>-Objekts diese Aufgabe für uns übernimmt. Sollten Sie für andere Aktionen in diesem Zusammenhang eine offene Verbindung benötigen, können Sie diese mit <b>Open <\/b>öffnen, müssen dann aber auch mit <b>Close <\/b>für das Schließen der Verbindung sorgen.<\/pre>\n
Das DataTable<\/b>-Objekt erzeugt die Methode zunächst einfach nur und speichert es in der Variablen dt<\/b>. Das Füllen dieses Objekts erfolgt nicht über eine Methode des Objekts selbst, sondern das Objekt wird als Parameter der Fill<\/b>-Methode des DataAdapter<\/b>-Objekts übergeben:<\/p>\n
da.Fill(dt);<\/pre>\n
Nun enthält das DataTable<\/b>-Objekt bereits alle Datensätze mit allen Feldern der Tabelle tblKategorien<\/b>. Diese durchläuft die Methode in einer for<\/b>-Schleife mit der Laufvariablen i<\/b>, welche die Werte von 0 <\/b>bis zur Anzahl der Datensätze minus eins durchläuft. Die Anzahl der Datensätze ermitteln wir hier mit dem Ausdruck dt.Rows.Count<\/b>. Rows <\/b>ist die Auflistung aller Datensätze.<\/p>\n
Über diese Auflistung erhalten wir mit dem entsprechenden Indexwert ein DataRow<\/b>-Objekt, das wir mit jedem Schleifendurchlauf neu mit der Variablen row <\/b>referenzieren:<\/p>\n
DataRow row = dt.Rows[i];<\/pre>\n
Über den Index der Felder gibt die Methode nun die Inhalte der ersten beiden Felder in der Konsole aus:<\/p>\n
Console.WriteLine(\"{0} {1}\", row[0], row);<\/pre>\n
In dieser Anweisung könnten wir auch konkret auf die Feldnamen zugreifen:<\/p>\n
Console.WriteLine(\"{0} {1}\", row[\"KategorieID\"], row[\"Kategoriename\"]);<\/pre>\n
Anschließend gibt die Methode die Liste der Kategorien aus der Tabelle tblKategorien <\/b>in der Konsole aus (siehe Bild 1).<\/p>\n
\"Ausgabe<\/p>\n
Bild 1: Ausgabe der Daten der Tabelle tblKategorien<\/span><\/b><\/p>\n
Wir haben nun das OleDbConnection<\/b>-Objekt und die SQL-Anweisung per Konstruktor an das OleDbDataAdapter<\/b>-Objekt übergeben. Sie können auch zunächst ein OleDbCommand<\/b>-Objekt erstellen und dieses dann als Konstruktor beim Erstellen des OleDbDataAdapter<\/b>-Objekts übergeben:<\/p>\n
string strConnection = \"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=Suedsturm.mdb\";\r\nstring strSQL = \"SELECT * FROM tblKategorien\";\r\nOleDbConnection cnn = new OleDbConnection(strConnection);\r\nOleDbCommand cmd = new OleDbCommand(strSQL, cnn);\r\nOleDbDataAdapter da = new OleDbDataAdapter(cmd);<\/pre>\n
Oder Sie verwenden beim Erstellen des DataAdapter<\/b>-Objekts die konstruktorlose Variante und weisen das OleDbCommand<\/b>-Objekt erst im Anschluss über die Eigenschaft SelectCommand <\/b>hinzu:<\/p>\n
...\r\nOleDbCommand cmd = new OleDbCommand(strSQL, cnn);\r\nOleDbDataAdapter da = new OleDbDataAdapter();\r\nda.SelectCommand = cmd;<\/pre>\n
Warum ist hier von SelectCommand <\/b>die Rede, und nicht einfach von Command<\/b> Weil der DataAdapter <\/b>ja zunächst einmal Daten liefern soll. Daher soll das Command<\/b>-Objekt eine Select<\/b>-Anweisung enthalten und nicht etwa eine Aktionsabfrage.<\/p>\n
Anzahl der Datensätze per Fill<\/h2>\n
Wenn Sie ein DataTable<\/b>-Objekt mit der Fill<\/b>-Methode des DataAdapter<\/b>-Objekts füllen, liefert die Fill<\/b>-Methode einen Rückgabewert, den Sie hier direkt nutzen können: Es handelt sich nämlich um die Anzahl der zurückgelieferten Datensätze. Im folgenden Ausschnitt der Methode DataTableFuellenIV <\/b>schreiben wir das Ergebnis der Fill<\/b>-Methode in die Variable anzahl<\/b>, die wir dann als Vergleichswert des zweiten Parameters der for<\/b>-Schleife nutzen:<\/p>\n
...\r\nDataTable dt = new DataTable();\r\nint anzahl = da.Fill(dt);\r\nfor (int i = 0; i < anzahl; i++)\r\n{\r\n     DataRow row = dt.Rows[i];\r\n     Console.WriteLine(\"{0} {1}\", row[0], row);\r\n}\r\n...<\/pre>\n
DataTable per foreach durchlaufen<\/h2>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Visual Basic Entwickler<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 200 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t
\n\n\t\t\n\t\t