2 verknüfpfte Tabellen anzeigen, aktualisieren und Abspeichern unter zu Hilfenahme von DataBinding

Du meinst mit doppelter Anzeige wohl, dass der Architekt mehrmals in der Dropdown-Liste aufscheint?
Dazu wäre es gut, ein kleines Sample hochzuladen, dass diese Erscheinung zeigt...

Die Combobox zeigt doch eh ganz normal an...
Oben ist dein ausgewählter Architeckt und unten in der Liste ist er einmal zum Auswahlen angeführt - was passt dir den da nicht?

Was immer gern (falsch) gemacht wird ist, die Combo als combo direkt aus dem Datenfenster zu ziehen. Das mach ich in meine Videos nicht so vor, weil der Designer konfiguriert da einfach Müll.
Sondern Combos muss man aus der Toolbox holen und selbst anschließen - wie im Video gezeigt.

Ansonsten muss man das Projekt halt selbst angucken - vlt. stimmt was mitte BindingSources nicht, oder mittm Datenmodell insgesamt oder was immer.

jo, binnich gespannt.
vlt. mach ich im Tut noch fetten Hinweis, rot, mit Rufzeichen und so, dass man Combos nur ganz genau so wie gezeigt binden soll, und nicht anders.

ja, stimmt.
Eine Combobox hat die SelectedItem-Eigenschaft, mit der man angeben kann, in welche Bindingsource und auf welche Property sie ihren SelectedValue schreiben soll bzw. davon lesen.

Also der Witz, das Schwierige und das Mächtige an Combobox ist, dass sie an beide BindingSources gebunden ist: Ihre Datenquelle (DataSource, von wo sie auswählt) ist die ParentTable, aber die getätigte Auswahl (ValueMember) ist gebunden an die Fremdschlüssel-Spalte der ChildTable.
Ein gleiches kann man auch mit Listboxen erreichen, aber nicht mit DatagridView.

Bei DatagridView müsste man Events von BindingSources verarbeiten, wo diese Synchronisation dann durch User-Code vollzogen wird.
Ich hab ja allerlei Erweiterungen zum Problemkreis WinForms-Databinding verzapft, son Synchronisator ist auch irgendwo dabei.

Aber ein DGV ist natürlich auch keine Combo, als AuswahlControl nimmt das ja viel mehr Platz ein.
Daher schon korrekt, wenn du da eher eine mehrspaltige Combo zurecht-bastelst.
Oder vlt. noch besser (v.a. einfacher), du ordnest der Combo ein paar weitere Labels bei, die - als eigener DetailView, jetzt der Combo-Datenquelle - die ArchitekturBüro-Zusatz-Infos präsentieren.
Das wäre mit einfachsten Mitteln von der Stange machbar, dabei aber absolut präsentabel.

Übrigens statt Pdf kannst du auch Bilder - png - Dateien anhängen, die kann man im Forum komfortabler angucken - auch dazu habich Tut verbraten:

nein, hat sich überhaupt nicht durchgesetzt - gilt als voll veraltet.
Der Hype liegt voll auf EF.

Allerdings fund ich noch kein wirkliches Argument gegen Datasetse. Dafür finde ich aber allerlei Nachteile von EF. Eine wirklich relational tickende Oberfläche damit zu basteln ist mir bislang kaum gelungen.
Also für mich ist der m:n-View die Messlatte, du musst etwa per Combobox einem Projekt einen anderen Bearbeiter zuordnen können, und im selben Moment hat das Projekt auch aus der Übersichts-Ansicht seiner Projekte zu verschwinden, und muss dafür in der Übersicht des neuen Bearbeiters wieder auftauchen.
EF zickt da elend herum.
Ausserdem soll man EF-DataContexte nicht lange aufheben - das kapier ich garnet so recht. Das führt ja dazu, dass man Datenmodelle lädt und entlädt, und damit spaziert man direkt in lausige Redundanz-Probleme hinein, wenn die Daten mehrfach vorhanden sind. Bzw ganz unnötiger Db-Traffic.
Ausserdem kann man EF garnet ohne DB entwickeln - MickiSoft-GeschäftsGebahren - die wollen halt ihre Produkte verkaufen.

Hier, denk mal da drüber nach - die Vorbemerkungen: Daten laden, speichern, verarbeiten - einfachste Variante

Ich hab den Kofler nicht gelesen, aber was du kolportierst ist gradezu ärgerlich.
Wenn irgendetwas undurchsichtig ist, dann doch wohl, was das EF im Hintergrund treibt, wenn man im Vordergrund sone dolle Linq-Queries hinschreibt.
Und versionsabhängig sind ja wohl die Db-Provider, die MS einen nach den anderen auswirft - simmer eiglich schon bei SqlServer2015?

Und ist nicht so, dassichs mit EF nicht versucht hätte - gugge EntityFramework-CodeFirst-Sample - das ist das beste, was ich hinbekommen habe.
Wie gesagt, das verhält sich weniger konsistent als eine Dataset-Anwendung, und ausserdem behält es im Repository den DataContext, weil anders wüsste ich die m:n - Funktionalität garnet bereitzustellen.

Aber quasi hat Kofler recht: Dataset ist veraltet, und EF ist viel doller.
Einfach, weil diese Meinung zum Standard gemacht worden ist.

kein Problem. Aber hast du die verlinkte Vorbemerkung mal gelesen?
Weil grad bei dir wäre eine DatasetOnly-Entwicklung sehr angesagt.

Ja, der Punkt den du ansprichst, da möchte man ja gerne noch eine Relation weiter hoch gehen, um auch Büro-Daten des Architekten zu sehen.
Da kommt dann doch eine berechnete Spalte in Frage, wo mehrere Attribute, auch von ParentRows, zusammengezogen sind. Ist im Grunde ein Manko des WinForms-Bindungssystems.

Übrigens den BindingNavigator würd ich unbedingt runterschmeissen vom Form.
Wenn man im DGV (oder auch nur in einer Combo) Datensätze auswählen kann - wer wird denn dann per "Navigator" Klick für Klick sich da durch-Klickern wollen? stell dir mal vor, du hast auch nur 100 Projekte!

genau.

Unglaublich, nicht wahr?

Aber denk mal drüber nach - argumentiert ist es ja.


Und wie gesagt, dich halte ich sogar für besonders geeignet, denn scheints kriegst du das Datenmodell in der Db aufzusetzen recht gut hin.
Es wird dir also wenig Probleme machen, mw. in 6 Monaten, wenn deine Anwendung so weit ist, die entsprechende Db aufzusetzen, und zu hinterlegen. Das wird dann vlt. 2-3h dauern, bis sie wirklich 100% passt, aber dafür sparst du dir die ganze Entwicklungszeit über das Rumschleppen und ständige Nachführen des "doppelten Datenmodell-Lottchens".
Und wie gesagt Portablität, Backup, Kommunizierbarkeit einer DatasetOnly-Anwendung ist viel besser.

mit Xml hast du nix zu tun - das macht Dataset.WriteXml.
Du kannst natürlich reingugge, wenn wolle, sogar - vorsichtig! - drin rumpfuschen.

Für auffn Server legen, und von mehreren aus bearbeiten ist das aber nicht geeignet.
Das ist genau das Gebiet, was richtigen DBs vorbehalten ist.

Und das wirft auch noch einige Probleme auf - zT. wirklich knifflig:

• inkrementelle Befüllung, also man will in einem Produktiv-System ja nicht die ganze Db laden.
  
• DbConcurrency - also konzipieren und absichern dagegen, dass 2 User gleichzeitig denselben Datensatz bearbeiten und geändert rückspeichern wollen
• Sicherheit im Netzwerk - verschlüsselte Kommunikation
  

Aber das sind Probs, die man sich besser für später aufhebt (geht tw. auch garnet anders)

ach - für euer Ing-Büro?
Haste dich schon ausführlich auf dem Markt umgesehen?
Son Proggi verschlingt leicht viele hundert Mann-Stunden, also wenns was gibt, so ist eine Einkauf-Lösung höchstwahrscheinlich wesentlich billiger, bei evtl. besserer Qualität und Zuverlässigkeit.

wie gesagt: musst du nicht.
Du kannst ohne entwickeln, und sie hinterher wieder dranmachen.

(aber gugge auch mein edit oben, wg. Einkauflösung)