Wie geht DataGridView mit DB-Binding?

Hallo mal wieder,

ich will mir hier grade eine ganz einfache und kleine Anwendung zusammenstöpseln, in der ich Fahrtzeiten eintrage, die mir dann mit meiner eigenen Darstellungslogik visualisiert werden. Excel ist für diesen Zweck völlig ungeeignet, also muss ein eigenes Programm her. Da ich nicht viel Arbeit da reinstecken wollte, dacht ich mir, ich probier mal die volle Datenautomatik im VS2008 aus (mit Windows Forms, .NET 3.5).

Mein Form hat jetzt ein DataGridView, als Datenquelle hab ich mir eine SQL-Server-Compact-Datenbank erstellen lassen. Über den Dataset-Designer habe ich dort eine Tabelle angelegt. Die konnte ich als Datenquelle im DataGridView auswählen und er hat mir die Spalten eingefügt.

Wenn ich das Programm starte, kann ich Daten eingeben. Aber nach dem Beenden des Programms sind die weg und kommen beim nächsten start auch nicht wieder. Muss ich da irgendwas manuell laden oder speichern? In der MSDN stehen nur Codebeispiele, die alles manuell machen, inkl. ConnectionString. Ich gehe davon aus, dass ich damit nichts anfangen kann. Im Web wird auch nur auf diese MSDN-Doku verwiesen. Hier im Forum habe ich diese Frage nicht gefunden. Wie geht das also nun? Bislang war's ja ganz einfach, aber es funktioniert halt bloß leider nicht.

Bislang habe ich das DataGridView nur "manuell" verwendet, also Zeilen per Code mit Inhalten gefüllt, die ich mit eigenen SQL-SELECT-Abfragen aus einer Datenquelle gelesen habe. Da musste ich sie auch mit UPDATE/INSERT selbst wieder reinschreiben. Das wollte ich mir nun alles sparen. Soll ja wohl irgendwie gehen, nehm ich mal an.

Hi!

Wenn du im Dataset die Spalten angelegt hast, gibt es sie noch lange nicht in der Datenbank.

Das Daten-Layout muß in der Datenbank erfolgen.
Aus der DB kann dann das passende Dataset generiert werden.

Kannst auf Movie-Tuts das Tut "Datenbank in 10 Minuten" angucken, da wird sowas gemacht.

Wenn dein Teil aber so klein bleibt (wasweißich bis 10 MB Daten ist "klein"), dann kannste auf die DB komplett verzichten, und lädst und schreibst das Dataset einfach mit Dataset.ReadXml/.WriteXml.

Das ist auch noch superschnell im Zugriff.

Muss ich da irgendwas manuell laden oder speichern?

Zumindest musst Du das Speichern aktivieren. Woher soll NET/Windows wissen, dass Du Änderungen auch speichern willst?

Siehe die Einführung in 🛈 Kap.25 ff.

Entscheidend ist, dass irgendwo und irgendwie ein Befehl :rtfm: DbDataAdapter.Update aufgerufen und ausgeführt wird. Du brauchst also einen Button, der dies aufruft. (Dazu gehören aber noch mehrere Einzelschritte, deshalb gibt es von mir hier keinen Code.)

In der MSDN stehen nur Codebeispiele, die alles manuell machen, inkl. ConnectionString. Ich gehe davon aus, dass ich damit nichts anfangen kann.

Du meinst wohl, dass Du damit nichts anfangen willst. Aber so versteht man am besten, was wie gemacht wird.

Bislang habe ich das DataGridView nur "manuell" verwendet, also Zeilen per Code mit Inhalten gefüllt, die ich mit eigenen SQL-SELECT-Abfragen aus einer Datenquelle gelesen habe.

Gut, dass Du davon abgehst. Es ist in aller Regel der falsche Weg, die Zellen direkt mit Inhalt zu füllen; besser ist der Weg über eine Datenmenge wie DataTable.

Gruß Jürgen

@ErfinderDesRades: Du hast zwar recht mit Xml, aber LonelyPixel hat sich schon eine DB ausgewählt. Wenn er das schon so konsequent beginnt, sollten wir ihm davon nicht abraten.

Da ich nicht viel Arbeit da reinstecken wollte, ...

Danke für die Hinweise. Werd ich demnächst mal reinschauen.

Ich wollte zuerst eine XML-Datei verwenden, weil es wirklich nicht viele Daten sind (jeden Tag ein Datum, 3 Zeiten, eine Zahl und ein kurzer Text, und das über wenige Jahre wenn's hochkommt; keine Sortierung oder Filterung nötig). Aber im VS Designer stand XML nicht zur Verfügung. Also war die Compact-Datenbank von MS das naheliegendste. (Meine nächste Erfahrung diesbzgl. ist mit SQLite.NET.)

Woher soll .NET wissen, dass es meine Änderung speichern soll? Naja, ich habe die Verbindung zur DB angelegt und Bearbeiten/Hinzufügen im DataGrid aktiviert. Warum sollten Änderungen (nach dem Verlassen der Zeile, siehe Icon ganz links, so wie in MS Access) nicht auch gespeichert werden.

Nein, ich meinte schon "ich kann damit nichts anfangen". Deshalb, weil ich den Eindruck hatte, dass mit der Einrichtung im Designer alles erledigt wäre. Es sah ja auch so aus, nur dass nichts gespeichert/geladen wurde. Der ConnectionString ist z.B. bereits in einem der Konfigurationsdialoge aufgetaucht. Warum sollte ich ihn nochmal im Code eintragen? Da man alles komfortabel und manuell machen kann, sah es für mich so aus, als wäre in der MSDN der "manuelle" Weg beschrieben. Aber das werd ich ja noch erfahren, wenn ich mich da mal durchlese.

Wie gesagt: Die Frage der Persistenz ist mit diesen beiden Zeilen lösbar

this.DBSampleDataSet.ReadXml(_DataFile);
this.DBSampleDataSet.WriteXml(_DataFile);

und du könntest dich auf dein GUI stürzen.

Zu den Gestaltungsmöglichkeiten empfehle ich auch das Tut "DatasetOnly" auf o.g. Site.

Einen Data-Access-Layer kannste auch nachträglich noch unterschieben, von daher isses also nichtmal "dirty", so vorzugehen.

DataSet.Read/WriteXML hat keinen Effekt, der schreibt zwar die Datei, aber sie ist leer.

Ich hab das mit dem DataSet jetzt aufgegeben. Dieses Tutorial redet ewig im Kreis rum und macht alles mögliche im Schneckentempo, da wird man ja nie fertig. Ich will auch keine verdammte Access-Datei verwenden und wie man woanders eine neue Datenquelle anlegt, wird gar nicht beschrieben. Ich hatte halt auf ein paar Code-Zeilen gehofft, an denen man erkennen kann, wie es geht und die man dann verwenden könnte. Anscheinend ist es aber doch nicht so einfach. Da bin ich schneller fertig, wenn ich's gar selber mach. Da weiß ich wie es geht und es geht vor allem schnell und genauso wie ich es haben will...

Der Witz am Tutorial (und am Databinding überhaupt) ist, dass man (fast) keinen Code braucht.
Du kannst natürlich hergehen, und die Designer.xy - Dateien der beiliegenden Sample-Solutions angucken, da hast du Code, recht greulichen zwar, aber lauffähig.

Und kannst natürlich hunderte von Zeilen selbst schreiben, um etwa die Spalten eines DGVs in eine ansehnliche Form zu konfigurieren (wenn dir das Wysiwyg der Designer nicht zusagt).

Aber viel (User-)Code bedeutet viele Fehler, und viel Arbeit bei der Wartung.

DataSet.Read/WriteXML hat keinen Effekt, der schreibt zwar die Datei, aber sie ist leer. Eigenartig: Bei mir geht das.

Hier ist auch noch eine Sample-Solution in c# enthalten: Vorüberlegung zur Form2Form-Kommunikation

Und hier eine mit DataSet.Read/WriteXML: DataSet mehrmals verwenden und an mehrere Controls binden