Hi,
ich brauche eine Funktion mit der ich einzelne Zeilen aus einer DataTable löschen kann.
Microsoft schlägt mir das vor (angepasst): DataSet01.DataTable1.Rows(0).Delete()
Dann kommt allerdings die Fehlermeldung: Eine nicht behandelte Ausnahme des Typs "System.IndexOutOfRangeException" ist in System.Data.dll aufgetreten. Zusätzliche Informationen: An der Position 0 befindet sich keine Zeile.

In der DataTable steht aber definitiv was drinne. Jemand ne Idee?

Ich bin mir sicher, dass etwas in der DataTable steht, weil auf dem gleichen Form ein DataGridView mit DataBinding zu der Table vorhanden ist.
Und da sich in dem GridView jede Menge Daten befinden, die ich nicht erst vorher per Hand eingetragen habe, kann die DataTable nicht leer sein.
Es gibt auch nur eine Instanz dieser Table, von daher kann ich mir nicht erklären, wie es zu dem Fehler kommt.

Ich hab jetzt nochmal etwas rumprobiert. Wenn ich die Funktion vom Mainform aus aufrufe, wird brav die erste Zeile gelöscht.
Also auf Form1: mainform.delete() und dann auf dem Mainform DataSet1.DataTable1.Rows(0).Delete
Ergo wird zwar auf dem neuen Form ein DataBinding auf die erste Instanz erstellt. Funktionen auf dem Form beziehen sich dann aber
auf eine neue (und leere) Instanz des DataSets.
Das ist zwar nicht der schönste Weg Public Subs von anderen Forms aus auszuführen, aber wenns funktioniert soll mir das erstmal egal sein.

Mit dem Erkennen der Wichtigkeit der Information, hätte ich auch mein Problem sofort erkannt.

Das bei neuen Forms eigene Instanzen der DataSets erstellt werden ist mir bekannt. Ich verwende DataSets ja über mehrere Forms
hinweg. Nur war mir eben nicht bewusst, dass sich mein Lösungsansatz dazu nur auf die DataBindings der neuen Forms bezieht.
Funktionen beziehen weiterhin auf neue Instanzen. Diese Diskrepanz war die Ursache allen Übels.

Das verwende ich (leicht abgewandelt)

Aber das bezieht sich wirklich nur auf DataBindings und nicht auf Befehle die auf dem neuen Form ausgeführt werden. RowCount auf dem neuen Form ergibt 0, mainform.RowCount ergibt x, wobei auf beiden Forms die selben (nicht gleichen) Daten im DataGridview angzeigt werden.

Scheinbar stört es mein Program nicht, dass das nicht sein kann

Ich hab jetzt grad nochmal 1:1 die Vorlage von ErfinderDesRades eingesetzt. Selbes Ergebnis. Row.Count auf main > 0, bei Form1 = 0, in beiden Views finden sich identische Daten.
Aufgerufen wird das Form mit folgendem Befehl:


Wenn jemand eine Idee hat, wie es zu diesem Verhalten kommt, nur her damit. Solange muss OOP halt draußen bleiben.

Ps: Option strict = on

ErfinderDesRades schrieb:

VB.NET-Quellcode

1. frm.DataTable1BindingSource.DataSource = Me.DataSet1

Steht so im Tutorial. Mir ist schon klar, was du meinst, aber ich habe mich in diesem Fall 1:1 an die Vorlage gehalten und das DataBinding des DataGridview funktioniert auch perfekt.
Die 0 hat auch keinen Einfluss, die hab ich an allen erforderlichen Stellen eingefügt um das Ganze besser auseinander halten zu können.

es gibt nur das eine, was ganz zu Beginn des Projekts direkt nach dem ersten Form erstellt und umbenannt wurde. Wie kann ich denn am besten prüfen, ob es noch weitere Anwärter geben könnte?
Manuell erstellt hab ich garantiert kein weiteres DataSet.

Das hat nichts mit ignorieren zu tun.

Wenn ich das Programm starte werden Daten aus einer xml-Datei ins Mainform geladen. Das sind 5 DataTables mit jeweils 3 Spalten und ca. 30 Zeilen die mit Integern und Strings gefüllt sind.
Auf dem Mainform ist noch alles Sonnenschein. Die Daten werden vollständig und korrekt angzeigt. Ich kann z.B. per DataGridview, aber auch mit Befehlen Werte auslesen und eintragen. Wenn
ich dann speichere werden alle Daten an der richtigen Stelle in der .xml abgelegt. Ich hatte bei meinen inzwischen zahlreichen Versuchen nicht einmal den Fehler, dass Daten verschwunden sind,
oder ich auf eine leere DataTable zugreifen wollte.
Wenn ich jetzt mit dem o.g. Befehl ein neues Form öffne, werden im DataGridView die selben Daten angzeigt. Wenn ich da was ändere, ändern sich auch die Daten auf dem Mainform in Echtzeit.
Auch hier verschwinden in der akutellen Version keine Daten, es lassen sich keinerlei Fehler provozieren. Das Ganze läuft wirklich absolut rund und ist seit einer Woche auch fehlerfrei von Dritten
im Einsatz.
Wenn ich allerdings im neuen Form per Quellcode auf die Daten zugreifen will, treffe ich eine neue Instanz von DataSet01 an, die keine Daten enthält. Das habe ich aber weiter oben auch schon so
geschrieben. Der Befehl, mit dem das neue Form geöffnet wird und die Bindings übertragen werden, habe ich 1:1 aus dem Tutorial übernommen.