Kannst du mal ein konkretes Beispiel geben, mit Tabellen, die du brauchst (als Screenshot) und was du haben willst?

gugge JoiningView auf vier Views-Videos

Sql-InnerJoin ist unbrauchbar, denn solch Queries kannst du prinzipiell nicht editiert zurückspeichern.

beim typDataset ruft man die Daten nach Tabellen getrennt ab, und hält sie auch getrennt im typDataset. Der Joining-Vorgang findet erst im DGV statt, und bietet dort die verblüffende Option, dass man nun auch Zuordnungen editieren kann, indem man einen anneren Fremdschlüssel wählt.

gugge dort auch m:n-View

fichz schrieb:

Es werden ja die Daten je Tabelle mit dem .Fill des TableAdapters eingelesen oder?

Nein, die Beispiele sind noch simpler, die sind ja DatasetOnly.
Ich sag ja immer, man soll das trennen: DB-Zugriffe lernen von Dataset lernen, denn Dataset lernt man besser ohne dass gleich auch noch die DB-Zugriffe 100% tipTop sein müssen.

Ansonsten hast du recht: Bei mit DB-Zugriffe werden die im View gejointen Tabellen mit .Fill eingelesen, standardmäßig mit TableAdapter.Fill.
Ich selbst halte ziemlich wenig von den generierten TableAdaptern - das ist pro Tabelle > 200 Zeilen generierter Code, eiglich ganz unnötig, denn man kann viel besser dynamisch DataAdapter (beachte den Unterschied!) konfigurieren - das sind vlt. 300 Zeilen, aber die gelten dann für alle Tabellen in allen Datenbanken auf allen DB-Systemen.

Bei den TableAdaptern kann man im DatasetDesigner auch Filter und was konfigurieren - aber dassis immer sowas von aufgeblasen! Und man kann glaub sogar das TableAdapter-Sql so einstellen, dass die geladenen Tabellen nicht mehr zum Dataset kompatibel sind - also da guckstedann aus Wäsche.

Stattdessen habich DBExtensions programmiert, ein Framework, wo die Fill-Funktionen als Extension-Methods implementiert sind.
Diese Fill-Methoden haben Überladungen, wo man eine halbe Sql-Query angeben kann - nämlich vorzugsweise den WHERE-Abschnitt - das wäre dann dein Filter.
Aber es gibt da auch intelligentere .Fill-Überladungen, die man beauftragen kann, die notwendigen Sql-Inner Join - Formulierungen selbst zu generieren.
Weil wenn du einen Datensatz hast, und der ist mit 2 anneren Tabellen verknüpft, dann ist ja vom Prinzip her alles klar, was geladen werden muß, da brauch sich nicht ein Programmierer das Hirn zermatern, um das Sql dafür auszubaldowern.
Gugge dort mal das NorthWind-Project, da im HauptForm werden initial alle Kunden geladen, und von den Bestellungen und BestellDetails wird immer nachgeladen, wenn grad ein bestimmter Kunde selektiert wurde. (Beachte die Sql-Logs im Ausgabefenster).

Noch ein Gedanke zu Performance: Wird im View gejoint, so müssen die notwendigen Tabellen getrennt geladen werden, das sind mehrere Sql-Commands. Dafür aber haben die übertragenen Tabellen weniger Spalten, und das reduziert den Traffic u.U. wieder.
guck, wenn du 20 Bestellungen lädtst, mit je 30 BestellDetails.
Mit Sql-InnerJoin sind das 600 Datensätze, und jeder hat alle Spalten der BestellDetails und alle Spalten der Bestellungen.

Lädtst du getrennt, so hast du 20 Bestellung-Datensätze mit nur den Bestellung-Spalten. Und dazu (LöwenAnteil) 600 BestellDetail-Datensätze - aber die haben jetzt auch nur die Spalten der BestellDetails!

Nur als Überlegung - getestet habichdas noch nie, ab wieviele Spalten und wie was da performancemäßig die Nase vorn hat. (Viel wichtiger ist ja, dass die zusammengerührte Sql-Tabelle nicht rückspeicherbar ist).