Ostseebengel74 schrieb:

Alle Verweise sind in den Regeln auf Cascade eingestellt.

Das ist unkorrekt formuliert, aber doch klar erkennbar, dass du meinst: "Alle Relationen haben DeleteRule.Cascade eingestellt" ("Verweis" ist in Teilen was ähnliches, aber doch bischen was anderes (und sowas sind mit die schlimmsten Begriffs-Verwirrungen ))
Ansonsten ist (durch die klare Begrifflichkeit) deine Frage doch beantwortet - "DeleteRule.Cascade" kann doch nichts anderes heissen als Löschweitergabe, und was das wiederum heisst, ist doch selbsterklärend, odr?

Hättest du keine Löschweitergabe - dann würde deine Auftraggeber-Löschung zur Verletzung der Integrität führen, und vom Dataset abgelehnt.

---

Du kannst übrigens Relationen sogar ohne ForeignKey-Constraint einrichten, d.h. ohne Überprüfung der referenziellen Integrität.
Dann kannste Auftraggeber löschen und Kunde und Objekt kratzt das nicht.
Tätst dir aber keinen Gefallen damit.

Ich empfehle immer mit ForeignKey-Constraint, und sogar mit Löschweitergabe - selbst wenn Löschungen nicht vorgesehen sein sollen.
Löschungen verhindern ist ggfs. Aufgabe des Programms.
Das muss es sowieso leisten, weil damit umgehen, wenn ein Dataset (oder gar eine Datenbank) eine Löschung ablehnt (also wenn Kind schon in Brunnen) ist deutlich aufwändiger.
Aber ohne Löschweitergabe modellieren kann man auch für sinnvoll halten, besonders im ProduktivBetrieb.
Während der Entwicklungszeit ists jedenfalls gelegentlich vorteilhaft, seine Testdaten auch mal löschen zu können, ohne gesteigerten Aufwand des händischen Beachtens der Daten-Integrität.

---

Was ich dir noch sehr empfehle: Probiers aus.
Das kann durchaus Spass machen, ein Test-Progrämmchen basteln und gucken, wie sich das System unter verschiedenen Konfigurationen verhält.
Und ist das bessere Lernen, wenn Theorie und Praxis zusammenfinden.

Vielleicht ist das hier auch mal interessant für dich
Fragen zu Dataset->Db

Oder auch Daten laden und speichern
Es ist nämlich vom Lernen her höchst ineffektiv, bei einer Datenverarbeitungs-Anwendung sich gleich die sehr hohe Komplexität einer Datenbank ans Bein zu binden.
Dem Zugriff auf Datenbank sollte unbedingt vorrausgehen, dass man sich mit relationaer Modellierung, Databinding, Usercontrols, Layout gut auskennt.
Also die ganze Anwendung sollte man immer (gilt auch für Kenner der Materie) erstmal ohne Datenbank ausprogrammieren, und statt Datenbank einfach eine Dataset-xml-Datei verwenden.
Das ist bereits Stoff reichlich genug, aber wenn man gleichzeitig mit DB einsteigt hat man ein zweites fast ebenso komplexes Thema am Hals, und Komplexitäten addieren sich nicht, sondern sie multiplizieren sich.
Einen kompletter Lernplan gibt hier: Datenverarbeitungs-Vorraussetzungen
(Und du stehst da ziemlich am Anfang, ich hab Code von dir gesehen, da ist noch nichtmal Option Strict On aktiviert.)

Ostseebengel74 schrieb:

ist das setzen von WriteSchema erforderlich?

wie ich sagte:

ErfinderDesRades schrieb:

Probiers aus.

Und guck auch in die entstehenden Dateien hinein.
Tatsächlich kannte ich die zweite Variante garnet, hab jetzt im Objectbrowser nachgeguckt, wasses damit auf sich hat. Ich verrats aber nicht, weil du ja auch selbst nachgucken kannst.
Kann ich sehr sehr empfehlen, sich mit derlei Fragen immer erstmal vertrauensvoll an den Objectbrowser zu wenden.

Hast du in die Dateien geguckt?
Hast du auch die anderen XmlWriteMode-Werte ausprobiert?
Und im Objectbrowser haste wohl nicht wirklich geguckt, zumindest ohne "browsen". Weil wie gesagt, da steht was dazu.
(Ich hoffe nur, dass es richtig ist, ich hätte eigentlich schon Unterschiede bei den Dateien erwartet)

Jo, sowas gibts oft.
Eine Methode ist wie hier mehrfach überladen, und die Überladungen unterscheiden sich nur am zusätzlichen Parameter.
Dann ist die Methode ohne den zusätzlichen Parameter die meistverwendete, einfacher aufzurufende.
Intern ruft sie dann die mit dem zusätzlichen Parameter auf, wobei sie einen hardcodet Standard-Wert übergibt.
Also im Grunde wird immer die mit beiden Parametern aufgerufen, nur wenn man ihn weglässt, wird ein Standard-Wert eingesetzt.

Kannst du inzwischen mit dem Objectbrowser umgehen?
Weil dann kannstes ausprobieren, und guckst dann im OB nach, welche Methoden bei welcher Einstellung im TableAdapter generiert werden, und wie die ticken.
Die Namen kann ich schon verraten: die eine heisst FillByAktiv(), und die andere GetDataBy().
Nun gilt es, den Assistenten fertigstellen zu lassen, und dann im OB gucken, was er gemacht hat.
(Du kannst die Namen auch ändern, aber warum? sind doch gute Methoden-Namen, die sagen, was sie tun)

Ostseebengel74 schrieb:

bzw. kann die SQL Anweisung für diese anders sein?

Das geeeht auch, dürfte aber ins Chaos führen.
Stattdessen ist vorgesehen, dass du dem TableAdapter weitere Abfragen hinzufügst (natürlich mit dem Sql deiner Wahl)

komisch.
Wenn bei mir eine Methode FillByAktiv existiert, und ich im OB nach Fill suche, dann wird die auch gefunden.
hattest du vlt. noch nicht kompiliert?

---

Aber ansonsten hast du doch kein Problem - die gezeigten Methoden sind gut benamt, und tun doch, was sie sollen - oder?

Wenn du weitere möchtest, kannst du ja weitere hinzufügen.