also wenn ich dir jetzt folgen konnte..

Dann ist das so.
Die Abhängigkeiten kannst ja danach erstellen. Aber sonst ist je Tb für sich.

VB1963 schrieb:

Wenn man Access verwendet, muss man dort alle Tabellenbeziehungen angeben
Oder genügt es, erst im Dataset die Tabellenabhängigkeiten anzugeben...

Die Frage geht an jede DB - nicht nur an Access.
Prinzipiell reichts, die Beziehungen nur im Dataset zu konfigurieren, und inne DB ein weniger streng geprüftes Datenmodell zu haben.
Allerdings verzichtet man dadurch auch auf die Löschweitergabe beim Rückspeichern von Deletes von übergeordneten Datensätzen.

Was ich als Save-Methode immer implementiere, das nutzt sowohl im Dataset als auch inne DB die Löschweitergabe. Will man darauf verzichten, so muß man eine andere Lösch-Methode schreiben, welche rekursiv zunächstmal die ChildRows löscht, bevor die eigentliche Datarow weggehauen wird.

Das ist etwas mehr Aufwand, und im Betrieb auch etwas mehr DB-Traffic.

Aber grundsätzlich würde ich immer sehr drauf gucken, beide Datenmodelle, also die DB und das Dataset, strukturell möglichst identisch zu halten.
Hingegen wenn man weiß, was man tut, eröffnen sich natürlich auch Möglichkeiten grade aus der Möglichkeit, Besonderheiten im Dataset einzubauen, die man inne DB nicht haben will.
Etwa die Möglichkeit, im Dataset mittels Hilfstabellen User-Auswahlen zu modellieren und zu verarbeiten.
Solch temporäre Informationen gehören ja nicht in die Datenbank-Datei geschrieben - aber im Gui isses sehr praktisch, wenn man an sowas binden kann.

ErfinderDesRades schrieb:

Allerdings verzichtet man dadurch auch auf die Löschweitergabe beim Rückspeichern von Deletes von übergeordneten Datensätzen.

Verdammt
Ich mach das auch so, dass ich meine DB relativ 'dumm' halte und das lieber im DataSet modelliere. Wenn ich wieder zu Hause bin, muss ich gleich nachsehen, ob da in meinen Detailtables diverse verlorene Datensätze rumschwirren. Aber dann führt einen der DataSet-Designer übel aufs Glatteis: Ich hab da meine ganzen Relations zwischen den Tables definiert und - wo es sinnvoll ist - immer brav angegeben, dass referentielle Integrität gelten soll. Mit kaskadierend und allem SchickiMicki. Wenn ich mir mal die DB beim Rumprogrammieren geschreddert habe, dann hat mich VB beim Folgestart auch angemeckert, wenn die referentielle Integrität verletzt war und deswegen die DB net geladen werden konnte.
Das DataSet gibt den Löschbefehl nicht kaskadierend weiter???

Wenn im Dataset für eine Beziehung DeleteRule.Cascade eingestellt ist, erhalten untergeordnete DataRows natürlich ebenfalls RowState.Delete gesetzt.

Das hat aber nix mit der DB zu tun. Ein Dataset "gibt keinen Löschbefehl" an die DB - das machen ja die DataAdapter.
Auch bei meine DBExtensions machen das DataAdapter, und wie gesagt: ich habe deren Abspeicher-Strategie nicht-rekursiv implementiert, sondern wird im Dataset Löschweitergabe vorgefunden, so wird diese dann auch inne DB vorrausgesetzt und ausgenutzt.