Dynamisches DataBinding für DataGridView in Multidatenbankanwendung

Hallo,

ich versuche mal mein Vorhaben zu schildern. Ich bin dabei eine Datenbankanwendung, welche derzeit mit einem Access Frontend und einer SQL Datenbank läuft nach C# zu portieren.
In der Anwendung werden Datenbanken angelegt und mit ihnen gearbeitet. Es wird auch innerhalb des Programms zwischen den Datenbanken gewechselt. Pro Monat wird eine neue Datenbank erstellt und damit gearbeitet.

Nun möchte ich in C# die Oberfläche neu schreiben, SQL Server soll weiterhin als Quelle dienen. Nun frage ich mich, wie ich das Befüllen der Datenbank (10 Tabellen, miteinander verknüpft) mit DataGridViews am besten hinbekomme. Ich habe schon rumprobiert, aber ich finde das alles recht umständlich.
Im Visual Studio kann ich zwar wunderbar eine Datenquelle hinzufügen, aber das bringt mir nichts, weil ich zur Laufzeit zwischen den Datenbanken auf einem Server wechseln muss. Das führt mich zu Problem Nr. 2. Wie kann ich für mein Programm (MDI-Applikation mit mehreren Forms) am besten global die Bindingsource für die DataGridViews festlegen ? Ich möchte nachher auch in den DataGrids Einträge hinzufügen und ändern können. Wie gesagt, das ganze muss zur Laufzeit variabel sein. Bisher habe ich das so gelöst, dass ich eine statische Klase habe in dem ich den Servernamen und die aktuell gewählte Datenbank halte, damit die GridViews eben immer diese Datenbank als Source nehmen. Allerdings kann ich so kein Update ausführen und keine Änderungen in die Datenbank schreiben.

Wie würdet ihr das am geschicktesten lösen ?

Vielen Dank für eure Gedanken !

Pro Monat wird eine neue Datenbank erstellt und damit gearbeitet.

Klingt schon mal als könnte es sich lohnen, das nochmal zu überdenken. Muss das unbedingt sein?

Ich weiß zwar dass es die ganzen Datenbindungs-Dinge gibt, aber ich nutze sie nicht oft. Mir ist das zu kompliziert, vor allem wenn Änderungen anstehen. Da weiß ich einfach nicht was wirklich passiert und ich greife lieber nur im Code ein, statt im Code (was oft unweigerlich ist) und zusätzlich noch im Designer. Nur als Überlegung, wenn du planst was du wie machst.

Bisher habe ich das so gelöst, dass ich eine statische Klase habe

Wenn ich jetzt sage dann nimm halt eine nicht statische und wechsel die je nach Bedarf?
Oder du designst deine Datenbank um und schreibst alle Daten in eine einzige Datenbank, mit dem zugehörigen Jahr als weitere Spalte. Dann kannst du sauber auf die Daten zugreifen.

Allerdings kann ich so kein Update ausführen und keine Änderungen in die Datenbank schreiben.

Mit statischer Klasse nicht? Warum das?

Was ich praktisch damit sagen will, ich glaub ich hab dein eigentliches Problem noch nicht ganz verstanden.

Hallo chilic,

Ich weiß zwar dass es die ganzen Datenbindungs-Dinge gibt, aber ich nutze sie nicht oft.

ich will nicht sagen, dass du damit alleine stehst, allerdings ist die regelmäßig im Forum ausgesprochene Empfehlung, DataBinding zu benutzen. DataBinding ist (mittlerweile) auf jeden Fall so ausgefeilt und flexibel, dass man damit alles realisieren kann. Gerade das DataGridView ist geradezu prädestiniert für DataBinding. Auch dass WPF, welches ja neuer ist als Windows Forms, noch stärker auf DataBinding setzt, ist ein Indiz für den Stellenwert und die Richtungsweisung von DataBinding.

Dass man zwischen Designer und Code springen muss, wenn man sich vom Designer etwas abnehmen lässt, ist ganz normal und hat nichts speziell mit DataBinding zu tun. Auch ohne DataBinding muss man das tun, wenn man nicht die gesamte Oberfläche von Hand als Code schreibt.

Wie dem auch sei. Wir haben jetzt Rede und Gegenrede. Jeder kann und muss sein eigenes Fazit daraus ziehen.

herbivore

Hi,

danke erstmal für die Antworten...

Zu den vielen Datenbanken. Die müssen leider sein, Hintergrund ist dass die Daten welche in einer Datenbank erzeugt werden nicht mehr verändert werden dürfen. Daher wird nach Beendigung der Arbeit mit einer Datenbank diese extern archiviert.
Also es bleibt dabei, es muss eine Möglichkeit geben innerhalb der Anwendung die Datenbank auszuwählen und dann nur mit dieser zu arbeiten.

Mein Problem ist eigentlich nur, wie ich das am elegantesten löse. Ich muss später auch noch durch die einzelnen Datensätze navigieren und in Abhängigkeit von Schlüsseln den Inhalt der DataGridViews anzeigen.
Unter Access ist vieles einfach schon vorgegeben, so dass man die gesamte Navigation nicht selber machen muss.
Bei C# , bzw. dem Visual Studio scheint das nur dann zu funktionieren, wenn die Anwendung mit einer einzigen Datanbankdatei arbeitet (*.mdb etc..)

Hi,

ich weiß nicht so richtig, wo das Problem ist? Du kannst doch den ConnectionString jederzeit ändern (auch zur Laufzeit).
Woher weiß die Anwendung denn, mit welcher Datenbank sie arbeiten soll (gibt es ein festgelegtes Namensschema z.B. "DB2012_01")?

Ich merk schon ich drück mich undeutlich aus 😁

Also ich weiß, dass ich den ConnectionString immer selbst anpassen kann.
Mir gehts eher darum, ob ich die Funktion "Datenquelle hinzufügen" im Visual Studio auch für dynamische Datenbanken nutzen kann. Das Schema in den Datenbanken ist ja immer das Selbe.
Dieser Automatismus bietet einige Vorteile, wie z.B. das Navigieren durch Datensätze oder die Generierung von Eingabeformularen.

Die Namen der Datenbank folgen einem Schema wie S-xxxx_abc

Ja und?
Auch für die Tableadapter musst du doch nur den Connectionstring anpassen.