Hallo @silverbob76GE

Ich kann mich irren aber ich denke das ist WinForms und nicht WPF, du hast zwar schon < 50 Beiträge aber ich denke du hast dich hier dennoch vertan.
Bitte kläre das mal und gib Bescheid.

Grüße
Sascha

Edit: Verschoben aus dem WPF Bereich

Arbeite auf den Daten.
AlleaufträgeRow hat eine Function GetEinzelaufträgeRows(), das sind die Einzelaufträge, die du kopieren willst.
Dann verwende die Einzelaufträge.AddEinzelaufträgeRow()-Methode, in der Überladung mit den vielen Parametern.
Die vielen Parameter diktieren dir genau, was alles du angeben musst, um die neuer EinzelaufträgeRow erfolgreich und gültig hinzuzufügen.

In BindingSources brauchst du da nicht rumzuhampeln.
Allenfalls wenn der Vorgang abgeschlossen ist, kannst du AlleaufträgeBindingSource auf die Position des neuen Alleaufträge setzen (aber das kann auch erstmal der User)

Fürchterliche Benamung hast du übrigens: Was bei mir ein Auftrag wäre ist bei dir ein AlleAufträge. Das ist schoma gelogen, denn ein Datensatz ist kein Plural, sondern nur einer.
Zum andern die Umlaute - sowas geht lange gut, fliegt einem aber iwann um Ohren, wenn iein Tool, oder auch das VS selbst, sich mit der Culture verhaspelt.

silverbob76GE schrieb:

Wie kann ich die Function GetEinzelaufträgeRows() aufrufen?

ErfinderDesRades schrieb:

AlleaufträgeRow hat eine Function GetEinzelaufträgeRows()

Mehr gibt es dazu nicht zu sagen.
Das mit der Benennung der DataTables ist eine Glaubenssache. Denn wenn ich eine DataTable namens Auftrag habe, dann würde es mich grausen, wenn ich schreiben müsste:

Oder mit der von mir bevorzugten LINQ-Variante: Auftrag.ForEach(Sub(x) …)
Wenn ich ne Liste habe, benenn ich sie auch im Plural: Dim Cookies As New List(Of Cookie) und schreibe dann Cookies.ForEach. Da hätte ich gern die Erklärung, warum ich bei ner DataTable-Benennung (und ja, jetzt sage ich es endlich mal: ich hasse das Wort "Benamung") Singular verwenden soll, obwohl ne DataTable viele Elemente enthält, aber ne Liste soll ich im Plural bezeichnen, weil Dim Cookie As New List(Of Cookie) ist ja ein Unding, Dim CookieList As New List(Of Cookie) ist redundant (Pseudo-ungarische-Notation) und mit sowas wie CookieBox fangen wir mal gar nicht erst an.
Das einzige Problem, was ich momentan beim Plural sehe, sind die automatisch erstellten Prozeduren des tDS. Cookies.AddCookiesRow(). Aber 1. kommt das bei mir selten vor und 2. ist das ein MSDN-Problem, welches man notfalls (!) auch noch durch Umbenennung (und nicht "Umbenamung") ändern könnte - sobald man mit der tDS-Konfiguation fertig ist.
@ErfinderDesRades: Verwendest Du das Wort "Benamung" mit voller Absicht oder ist das so ne Verballhornung wie "Datumse"?

##########

@silverbob76GE: Öhm, ja. Zeile#4 ist n bisken wenig. Du machst ja gar nix mit der Row.

Das ist eine Funktion, also eine Prozedur, die etwas zurückgibt.
Somit:
Und dann arbeitest Du eben mit DieEinzelaufträgeFürDieRow weiter. Was immer Du mit den Einzelaufträgen dieser Row auch machen willst.

Es sind viele Rows - also eher
Aber das ist nichts als die sklavische Anwendung dessen, was ich in post#4 bereits sagtete.
Das ist also recht problematisch, wenn du so eine einfache Aussage:

AlleaufträgeRow hat eine Function GetEinzelaufträgeRows()

nicht verstehst.
AlleaufträgeRow ist ein Datentyp - eine Klasse um genau zu sein.
Und dieser Datentyp stellt die Methode GetEinzelaufträgeRows() bereit.
Also alle Objekte vom Typ AlleaufträgeRow haben eine Methode GetEinzelaufträgeRows().

Da solltest du zusehen, deine Wissenslücken qualifiziert zu füllen - anders kann ich mir nicht vorstellen, dass man eine Datenverarbeitungs-Anwendung erfolgreich zu einem Abschluss bringen kann.
Grundlagen: Fachbegriffe
ist eine grob-Übersicht - was so Dinge wie Datentypen, Vererbung, Enums etc im einzelnen ist, da könntest du ein Online-Buch durcharbeitetn, etwa Kühnel/Leibhard (nicht den Theiss - der ist schlecht!)

Der erste Parameter stimmt nicht. Da will die Funktion wissen, wer oder was die ParentRow ist. Du gibst da aber ne leere, neue ChildRow an. Kompiliert das überhaupt? Ist doch der falsche Datentyp. Oder ist die DataTable irgendwo mit sich selber verknüpft? Bitte Screenshot des DataSet-Designers hochladen.

Ja, genau, sagt ja der Compiler: Er will ne AlleAufträgeRow. Du wolltest ihm aber in Post14 ne EinzelaufträgeRow unterschieben:

Das war mein Problem.
Du willst eine EinzelaufträgeRow erstellen. Die kann aber nur in Abhängigkeit von einer AlleAufträgeRow existieren. Ohne sie fehlt ihr was. Du musst dem Compiler quasi mitteilen, zu welcher ParentRow die neue ChildRow gehört.
Aber sag mal: In welche Tabelle gehört denn der Stornoauftrag? AlleAufträge oder Einzelaufträge?

Ich find das uneinheitlich, wenn du für AlleAufträge die NewAlleAufträgeRow() -Methode benutzt, für Einzelaufträge aber die AddEinzelaufträgeRow().
Ich empfehle wie gesagt, immer die Add<TypedRow>-Methode mit den vielen Parametern, weil auf diese Weise kann man keinen vergessen:
Bei der Überarbeitung habich auch gesehen, dass du jede Property typumwandelst, also bei String überall .ToString() dranhängst, bei Double mit CDbl() konvertierst, bei Decimal mit CDec() usw..
Typumwandlungen sind unleserlich und gefährlich.
Mach dir klar, dass, wenn du einen Typen umwandelst, dass du dann grad nicht typisiert programmierst.
Das typisierte am typisierten Dataset ist, dass die Spalten die richtigen Datentypen haben (die Typ-Umwandlungen hat der Designer im Hintergrund generiert - und der macht dabei keine Fehler).
Diese typisierten Spalten nochmal umzuwandeln in den Typen, des sie eh haben ist unnütz, und fehleranfällig, weil im Gegensatz zum Designer kann dir dabei ein Fehler unterlaufen.
Hingegen ohne selbstgebastelte TypUmwandlung sorgt der BackgroundCompiler für Sicherheit - du kannst gar keinen Wert mit dem falschen Datentypen eintragen - wird gleich rot gekringelt.

Generell gilt: "händische Typ-Umwandlungen vermeiden, wo immer es geht!"
Bei sauberer Programm-Architektur passen alle Typen immer genau zueinander, wie die verschiedenen Räder eines Uhrwerks.
Es gibt nur sehr wenige Ausnahmen, wo eine händische Umwandlung leider doch erforderlich ist (etwa beim rausholen der typisierten Row aus BindingSource.Current).
Diesem generellen Prinzip: "händische Typ-Umwandlungen vermeiden, wo immer es geht!"
ist das typisierte Dataset gradezu gewidmet.
Das typisierte Dataset erbt ja vom untypisierten Dataset. Und beim untypisierten Dataset muss tatsächlich jeder Wert beim Auslesen typ-gewandelt werden.
Aber um genau das loszuwerden ist ja das typDataset erfunden worden - und man sollte es unbedingt auch so benutzen.