die Zeilen 2-4, 7-9, 12-14,17-19 können weg, wenn du die jeweils andere AddDataTable<X>Row()-Überladung nimmst.
Auch scheint das Datenmodell verfehlt, denn scheinbar hast du mehrere Tabellen mit exakt derselben Struktur.
Bei richtig Modellierung gibt es in einem Datenmodell aber für eine Struktur nur eine Tabelle.
Hast du dein Modell entsprechend umgebaut, dann kommt man auch mit nur einer Add-Methode aus, und obige Geschichte vereinfacht sich noch einmal.

Und nebenbei: Boolean, Vergleiche und bedingte Verzweigungen

Hallo @Nils_Kr,
also ich würde um es etwas übersichtlicher zu halten leiber Select Case als mehrere If abfragen nutzen

kleines Beispiel:

LG Ruerte

Nils_Kr schrieb:

Tatsache, ein Spalte zur welcher Liste der Eintrag gehört hätte 3 DataTables überflüssig gemacht. Da aber schon Daten drinne stehen stehen lässt sich im Nachhinein nichts mehr dran ändern.

Von dieser Denke rate ich dringend ab.
Das Datenmodell ist das Fundament der Anwendung.
Ist ein Fundament fehlerhaft, wird das korrigiert - egal wieviele Stockwerke bereits drauf aufgebaut sind.
Das ist mühsam und teuer, aber unvergleichlich billiger als die Kosten, die entstehen, wenn man einfach weiter baut.
Und je früher man den Umbau anpackt, desto billiger - das billigste also ist: sofort.
(Und mach zuvor ein Gesamt-Backup, und teste das auf Lauffähigkeit, weil beim Umbau kann u.U. auch einiges irreversibel kaputt gehen)

Nils_Kr schrieb:

Könntest du bitte nochmal genau schreiben, wie der Befehl dann aussieht?

könnte ich.
Besser aber, du lernst, was eine "Überladung" ist (Grundlagen: Fachbegriffe), wie man im ObjectBrowser eine Methode in ihren vielen (in diesem Falle sinds jeweils 2) Überladungen auffindet, und wie man die im OB gemachten Angaben zur Aufrufe-Syntax praktisch in Code überträgt.
Kurz und kränkend (leider, aber nicht so gemeint): Lern programmieren.

zum OB: VisualStudio richtig nutzen (Google ist nicht deine Mami)
oder guck auch den Film "Inspection" auf vier Views-Videos, da wird ein typDataset im OB inspiziert, und werden auch die Add-Methoden kurz gefunden und erwähnt.

Ruerte schrieb:

VB.NET-Quellcode

1. If (Me.Controls("RadioButton" & i).ToString.Substring(Me.Controls("RadioButton" & i).ToString.Length - 4)) = "True" Then auswahl = i

@Nils_Kr Das ist suboptimal, da die Strings der Namen, wenn ein Control umbenannt wird, nicht mit umbenannt wird.
Um solch Information zu übertragen, nutze die Property Control.Tag, die kannst Du als String im Designer vorgeben.

@Nils_Kr ich kenne mich zwar in Sachen Datenbank nicht wirklich aus, solltest du so was in der Art wie

hinbekommen solltest du es um einiges kleiner bekommen (8Zeilen)

LG Ruerte

@Ruerte: fail, in mehrfacher Hinsicht. Insbesondere sind untypisierte Zugriffe echt NoGo, wenn typisierte Zugriffe parat stehen, die man nur zu verwenden braucht.

@Nils_Kr: Code posten ist gut, um einen funktionierenden Algo zu verbessern. Daraus ergibt sich ein unsystematisches, punktuelles Lernen, insbesondere von "Tricks" und Kniffen - ist durchaus wertvoll - aktuell hier etwa, dass man einen Boolean nicht mit True/False vergleicht.
Aber Grundlagen, wie Fachbegriffe, oder das VisualStudio effektiv zu nutzen, lernt man nicht an Code-Snippets. Im Gegenteil - wenn man gewöhnt ist, immer nur passende Snippets einzupasten, wird man nie dahin kommen, eine Vorgehensweise mal allgemeingültig zu formulieren, und so für sich an vielen Stellen verfügbar zu haben.
Ebensowenig kommt man über Snippet-Diskussionen dahin, ein fehlendes Detail, oder die Syntax einer Methode selbst nachgucken zu können.

@ErfinderDesRades wie bereits erwähnt

Ruerte schrieb:

kenne mich zwar in Sachen Datenbank nicht wirklich aus

Meine Rangehens weise an solchen Problemen ist:
1. Eine laufähige Möglichkeit so schnell wie möglich mit den geringsten aufwand finden.
2. Wenn zeit ist mich damit auseinander setzen und die Passenden stellen verbessern

aus dem Grund hieß es in meinen ersten Post auch nicht "hier die lösung ist gut" sondern

Ruerte schrieb:

kleines Beispiel:

Außerdem muss man dazu bedenken das nicht jeder 100% Zeit hat sich perfekt in eine Programmiersprache einzuarbeiten sondern nur als "kleines" Hobby an die Sache rangeht

Deshalb für dich auch mal ein lieb gemeintes

ErfinderDesRades schrieb:

fail

LG Ruerte

@Nils_Kr
ErfinderDesRades hat vollkommen recht, du solltest erst einmal dein Datenmodell überarbeiten. So wirst du dir früher oder später selbst ein Bein stellen bzw. hast es schon getan.
Mit nur einer DataTable könntest du dir vermutlich die Radiobuttons und die ganze IF -Abfrage sparen.


SelectCase Beispiel für radiobutton

Nils_Kr schrieb:

umgewandelt werden

War alles schon da.

nochmal zum Fundament:

Nils_Kr schrieb:

Das Programm läuft jetzt schon seit über einem Jahr ohne einen einzigen Ausfall und die abgelegten Daten sind relativ statisch.

Jo, dann muss man wohl auch abwägen.
Weil der Umbau kann u.U. einen Komplett-Rewrite bedeuten, evtl. sogar ohne für den User ersichtlichen Gewinn.
Andererseits, wenn du das Teil noch eine Weile supporten willst, ist auch ein ReWrite evtl. nicht zu teuer.

Ich für mein teil möchte nicht etwas supporten, wo im Datenmodell es ein Dataset1.DataTable1 gibt - allein solche Benamungen würden beständig meinen BlutDruck hochtreiben.

jo, sehe ich auch so: ob nu ElseIf oder Select Case ist geschmacksache.
Wenn Select Case, dann aber richtig: activevb.de/tipps/vbnettipps/tipp0006.html

@Nils_Kr in der Regel braucht Select Case weniger Ticks
(aber das ist bei so einer Kleinen abfrage letztendlich auch egal ^^)

LG Ruerte

Naja wenn du das beste aus der Situation machen willst wäre hier noch einmal ein Ansatz.

@Fakiz

denn

Fakiz schrieb:

Dim row = DataSet01.DataTable1.NewDataTable1Row()

stimmt nicht überall

Nils_Kr schrieb:

Dim row = DataSet01.DataTable1.NewDataTable1Row()
...
Dim row = DataSet01.DataTable2.NewDataTable2Row()
...
Dim row = DataSet01.DataTable3.NewDataTable3Row()
...
Dim row = DataSet01.DataTable4.NewDataTable4Row()