Datagrid updaten bei Änderung in anderem Datagrid

  • VB.NET

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von ruediger_006.

    Datagrid updaten bei Änderung in anderem Datagrid

    Hallo zusammen!

    Ich habe ein vb.net Programm mit zwei Formularen: 1. User können Daten in die Datenbank eintragen, 2. User können diese Daten abfragen, jeweils in einem Datagridview. Wenn meine user nun ihre Daten in 1. eintragen werden diese in 2. erst aktualisiert, wenn ich das Programm neu starte. Ich gehe mal davon aus, dass ich zu meinem selbstgenerierten Code (Datagridview wurde per Drag and Drop generiert)

    VB.NET-Quellcode

    1. Private Sub Overview_Load(sender As Object, e As EventArgs) Handles MyBase.Load
    2. Me.Overview_FMTONLY_OFFTableAdapter.Fill(Me.DataSet3.Overview_FMTONLY_OFF)
    3. End Sub


    Noch ein Update hinzufügen muss, weiss aber nicht genau wie. Ich habe es mit

    VB.NET-Quellcode

    1. Form2.DataGridViewForm2.Update()


    versucht, aber das Grid wird nicht geupdatet.

    Wäre super, wenn mir jemand helfen könnte.

    Beste Grüße

    Ruediger!
    Das Problem ist, dass in beiden Forms jeweils ein eigenständiges typisiertes Dataset existiert.
    Änderst du Daten in Form1, so weiß Form2 davon überhaupt nix - woher auch.

    Diese doppelte Datenhaltung ist ein grundlegender Design-Fehler von WinForms-Anwendungen: Redundante Datenhaltung ist der Tod einer jeden Datenverarbeitung.

    Eine Lösung habe ich mir in Viele DbSamples mitgeliefert, jedenfalls für Detail-Dialoge, wos also ein Hauptform gibt, und zur Bearbeitung poppt ein Detail-Form auf.
    Die Lösung ist ziemlich komplex (mit Reflection werden Dataset-Doubletten aus den Formularen rausgeschmissen), aber die Anwendung ist total einfach.


    kleine Abschweifung:
    Jedem Datenbänker - besonders Anfängern - empfehle ich, die Anwendung erstmal ohne Datenbank zu proggen, dassis einfacher, portabler, flexibler gegenüber Änderungen: Datenbänkerei-Einstieg
    Hi Erfinder!

    Danke dich werde mir das jetzt mal angucken. Eine Frage noch zu der Thematik. Beide Datasets füttern sich ja aus der gleichen Datenbank. Könnte man nicht einen Re-bind machen um das Problem zu lösen? Ich habe jetzt gerade mal

    VB.NET-Quellcode

    1. bs.ResetBindings(true)

    versucht, was leider nicht hingehauen hat. Aber wäre das nicht ein Ansatz?

    Beste Grüße
    nein. Ado.Net verarbeitet die Daten von der DB ungebunden.

    Es wird ein Batzen Daten geladen, dazu wird nur ganz kurz eine Connection geöffnet, und der DBProvider-Dienst abgefahren und blablaPipapo.
    Dannis Connection wieder zu, du hast deine Daten und kannst sie verwursten.
    Je nach Bedarf dann werden die lokalen Daten dann wieder mitte DB synchronisiert - in einer ebensolchen Blitz-Aktion, und dann ist Connection wieder zu.
    Dassis ein Sicherheits-Konzept (Netzverbindung darf auch zeitweilig unterbrochen sein), und minimiert ausserdem den DB-Traffic.

    Es wäre grober Unfug, diese Maschinerie jedesmal doppelt ablaufen zu lassen, wenn du in einem Grid ein Nümmerchen änderst.

    Wozu Daten an die DB schicken, um sie direkt danach vom anneren Form aus wieder abzurufen?
    Lass die DB im INet sein, dann geht die Schoose um die ganze Welt, und dabei hast du die Daten doch die ganze Zeit bei dir, direkt in deiner Anwendung!
    Also so Blödsinn fang nicht an.

    Nein. Der Architektur-Fehler ist zu beheben, also die Dopplung der Datasetse muß aufhören. Dann sind beide Forms ans selbe Dataset angebunden,
    und das Thema ist: verschwunden!! 8|

    Richtig gelesen: Das Problem verschwindet, sobald alle Bindings ans selbe Dataset gebunden sind: Gib auf Form1 "100" ein, gugge in Form2 - da steht sofort dann auch "100" - so ist Databinding, wenn mans richtig macht.
    Klar, klingt für mich absolut logisch!
    Wenn ich aber das erste Grid über eine Stored Procedure fülle die aus (sagen wir ServerTabelle1,2 und 3 filtert und dann eine Summe bildet und diese Tabelle dann in ein Dataset legt) und das zweite Grid sich nur aus ServerTabelle1 befüllt und diese füttert haben die Datasets ja eine ganz andere Struktur.
    Für mich wäre dann die Schlussfolgerung (damit ich es das nächste mal besser mache!) die ganze Datenbank in ein Dataset zu laden und dann die Berechnungen und Tabellen in vb.net anstatt in SP's zu erstellen.
    Dassis was ich sage: erst ohne DB anfangen!

    Kunststückchen wie StoredProcedures und Kram auf später vertagen. Wenn du in deine DB so dolle Proxy-Funktionalität einbaust, sodass die DataTables garnimmer der Tabellenstruktur der DB entsprechen, dann hast du nämlich auch das Vergnügen, diese Proxy-Funktionalität bis zum Ende durchzuziehen, also da wären jetzt weitere StoredProcs fällig, um Änderungen auch wieder abzuspeichern.
    Achja, und Inserts natürlich auch.
    Ups - fast vergessen: Deletes! man will ja auch mal einen Datensatz löschen!

    Hei - wieviele Tabellen hast du? :D

    Im Ernst: vergiss die DB, und mach erstmal ohne.
    Sql-Kunststückchen mach später, wenn du sehen kannst, wie man sie anlegt unter Wahrung der Kompatiblität zum Dataset.
    ZB Sql-InnerJoin generiert Datensätze, die prinzipiell nicht geändert rückspeicherbar sind, denn es sind ja aus mehreren Tabellen zusammengerühfte Datensätze - woher soll die DB wissen, was wohin kommt?
    In Ado.Net gibts eine bessere Alternative zum Select-InnerJoin - man hält die Tabellen getrennt, und rührt die Ansichten erst ganz zuletzt im Gui zusammen.

    Und nochmal wie gesagt:
    Dein Problem mit den beiden Forms verschwindet, sobald du das redundante Dataset rausschmeißt. Dann brauchst du auch nicht deswegen über weitere Kunststückchen nachzudenken, weil das Prob dann nicht mehr da ist.