Datenbanksynchronisierung bei Programmstart und -ende

  • VB.NET

Es gibt 49 Antworten in diesem Thema. Der letzte Beitrag () ist von MaThoPa1973.

    also ich kann dein Problem nicht reproduzieren.
    Hier eine DB-Anwendung.
    Im Testlauf wird die DB-Datei ins Ausführungsverzeichnis kopiert.
    Mittels des Test-MenuItems kann man nun zwischen der Haupt-DB und der Kopie im Ausführungsverzeichnis herumswitchen. In jeder der beiden DBs kannst du Änderungen vornehmen, sodass du innerhalb eines Testlaufes Unterschiede produzieren und verifizieren kannst.
    Dateien
    • SwitchDB00.zip

      (188,03 kB, 66 mal heruntergeladen, zuletzt: )
    Hey, das ist ja echt Klasse. Habe es mir angesehen. Habe aber inzwischen den Datentypenkonflikt den Gar ausmachen können.

    Der Code, um die Daten aus der Zentraldatenbank an die lokale Datenbank zu übertragen sieht jetzt so aus.

    Me.PatDataTableAdapter.Delete()
    Me.DGVPatData.Refresh()
    ' Me.PatDataTableAdapter.Update(Me.INRMSDataSet.PatData)
    Me.PatDataTableAdapter1.Fill(Me.INRMSZDBDataSet.PatData)

    PDCountZDB = Me.INRMSZDBDataSet.PatData.Count
    PatDataBindingSource1.MoveFirst()

    For PCZDB = 1 To PDCountZDB
    Me.INRMSDataSet.PatData.AddPatDataRow(DGVZDBPatData.CurrentRow.Cells(0).Value, _
    DGVZDBPatData.CurrentRow.Cells(1).Value, _
    DGVZDBPatData.CurrentRow.Cells(2).Value, _
    DGVZDBPatData.CurrentRow.Cells(3).Value, _
    DGVZDBPatData.CurrentRow.Cells(4).Value, _
    DGVZDBPatData.CurrentRow.Cells(5).Value, _
    DGVZDBPatData.CurrentRow.Cells(6).Value, _
    DGVZDBPatData.CurrentRow.Cells(7).Value, _
    DGVZDBPatData.CurrentRow.Cells(8).Value, _
    DGVZDBPatData.CurrentRow.Cells(9).Value, _
    DGVZDBPatData.CurrentRow.Cells(10).Value, _
    DGVZDBPatData.CurrentRow.Cells(11).Value, _
    DGVZDBPatData.CurrentRow.Cells(12).Value, _
    DGVZDBPatData.CurrentRow.Cells(13).Value, _
    DGVZDBPatData.CurrentRow.Cells(14).Value, _
    DGVZDBPatData.CurrentRow.Cells(15).Value, _
    DGVZDBPatData.CurrentRow.Cells(16).Value)
    PatDataBindingSource1.MoveNext()
    Me.INRMSDataSet.PatData.AcceptChanges()
    Me.DGVPatData.Refresh()

    Next

    Jetzt stellt sich aber das nächste Problem... das DGV wird aufgefüllt, allerdings werden die Daten vom DGV scheinbar nicht in die lokale Datenbank übertragen - die ist sowohl während das Programm läuft leer als auch nach Beendigung des Programms. (Sowohl die Datenbank im Lokalverzeichnis als auch im bin/debug-Verzeichnis. Habe ich irgend etwas vergessen oder übersehen??? ?(
    wie grässlich.
    Da hast du nun ein typisiertes Dataset, aber popelst immer noch Werte auss DataGridView, anstatt aus der typisierten DataTable.
    Und offenbar programmierst du auch Strict Off.

    Zum Topic im engeren Sinne:
    Ist dir klar, was AcceptChanges bewirkt?
    Accept Changes ist doch eigentlich die Anweisung alle Änderungen am DGV in der Datenbank zu übernehmen, oder nicht?
    Wenn ich also das DGV durch die zentrale DB auffülle stellt das doch also im eigentlichen Sinne eine Änderung im DGV dar???

    So, habe derweil auch mal auf Strict On umgestellt und alles angepasst.

    Wenn ich den AcceptChanges rauswerfe hat dies unweigerlich wieder den Datentypen-Error zur Folge ?(

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „MaThoPa1973“ ()

    MaThoPa1973 schrieb:

    Accept Changes ist doch eigentlich die Anweisung alle Änderungen am DGV in der Datenbank zu übernehmen, oder nicht?
    Nein, überhaupt nicht. Die Anweisung zur Sendung der Änderungen an die DB geschieht doch bereits im DataAdapter.Update() - Aufruf - oder wozu soll dieses dann gut sein?

    Wenn ich also das DGV durch die zentrale DB auffülle stellt das doch also im eigentlichen Sinne eine Änderung im DGV dar???
    Du füllst doch garnet das DGV durch die DB auf, du befüllst doch das Dataset!
    Deswegen findichs ja so gräßlich, dass du die Daten in untypisierter Form aussm DGV auspuhlst, wo die doch viel komfortabler und v.a. typisiert im Dataset rumliegen.
    Dassis wie eine Trinkwasserquelle im Garten haben, aber in die Stadt fahren, um Wasser in Plastikflaschen zu kaufen. ;)

    Aber nochmal zum AcceptChanges: Also Zeilen, die du nicht verstehst, und wo du kaum weißt, wo die herkommen (wird ja iwo abkopiert sein), und was die machen - schmeiß die raus, zumindest probeweise.

    Und machma Option Strict On!
    Strict On habe ich schon eingestellt und den Code umgestellt.

    AcceptChanges habe ich nirgends rauskopiert sondern durch testen verschieden Optionen gegen den Typen-Error gefunden. Nur wie gesagt, wenn ich den AcceptChanges raus werfe kommt die Fehlermeldung wieder.

    Und warum ich mir immer noch die Werte aus dem DGV puhle ist ganz einfach... ich bin irgendwie noch nicht dahinter gestiegen wie ich die Werte aus dem einen TableAdpater an den anderen übergeben kann. :( Ich teste noch ein wenig

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „MaThoPa1973“ ()

    naja - ich kanns jamal rauslassen: AcceptChanges ist nurwas für den internen aufruf durch den DataAdapter - Programmierer sollten die Fingers davon lassen. Der Befehl setzt den DataRowState auf Unchanged zurück, mit dem Ergebnis, dass der DataAdapter denkt, diese Zeile brauche er nicht an die DB zu senden.
    Daher ist auch auf einmal dein DatenTyp-Fehler weg, weil nämlich der Adapter nix mehr an die DB sendet. :thumbsup:

    MaThoPa1973 schrieb:

    Und warum ich mir immer noch die Werte aus dem DGV puhle ist ganz einfach... ich bin irgendwie noch nicht dahinter gestiegen wie ich die Werte aus dem einen TableAdpater an den anderen übergeben kann. :( Ich teste noch ein wenig
    Wieso Werte aus einem TableAdapter in den anneren tun??
    Erstmal sind in einem TableAdapter keine Werte drin - die sind im Dataset (sagte ich das schon?)
    Und wozu verwendest du mehrere TableAdapter?
    In mein Sample verwende ich denselben. Nur der ConnectionString des TableAdapterManagers wird geändert.

    Nochmal zusammengefasst: Die Daten sind im Dataset. Mit dem TableAdapter kann man sie an die DB senden, oder von dort abrufen und ins Dataset schaufeln.
    Die Controls sind ans Dataset gebunden. Controls stellen das Gui dar, das Graphic User Interface.
    Das heißt, controls sind für die User - sie zeigen ihm Daten an, und ermöglichen ihm, sie zu manipulieren.
    Die Controls sind nicht für codeseitige Datenmanipulation. Codeseitige Datenmanipulation führe man direkt auf dem Dataset aus, nicht an den Controls. An die Controls braucht man dabei nichtmal zu denken, denn über das Databinding aktualisieren die sich selbsttätig.

    Wenn man Daten braucht, hole man sie aus dem Dataset - nicht aus iwelchen Controls, und auch nicht aus TableAdaptern (wie immer das gemeint sein mag).
    Heißt also im Umkehrschluss...
    Ich nehme ein DGV und binde dieses an ein Dataset um dem Benutzer die Daten anzuzeigen.
    Und um die Daten von Lokal- an die Zentraldatenbank zu senden übergebe ich das DGV einfach an ein anderes Dataset weil dann der zum Dataset zugehörige TableAdapter dann die Daten an die Datenbank sendet? Hab ich das jetzt richtig verstanden?


    DB-Zentr. ---> DataSet ---> DGV ---> DataSet ---> DB-Lokal ???
    Die Daten sind im Dataset!

    Mit dem TableAdapter sendet man die Daten aus dem Dataset an die Datenbank!

    Ein DGV übergibt man niemandem!!


    Was zum Kuckuck hast du jetzt mit einem zweiten Dataset vor?

    Sind die Daten in dem einen Dataset irgendwie nicht gut?


    So, jetzma ohne Geschrei:
    Sone Synchronisiererei zweier strukturell gleicher DBs ist schon ein spezialfall.


    Ah - ja. Also ich kenn mich da nicht so aus, aber offensichtlich gibts da bereits ausgearbeitete Konzepte. Wikipedia1,Wikipedia2

    Bist du dir sicher, dass du das selber frickeln möchtest?

    Es sind ja übrigens 2 ganz verschiedene Anwendungen. Einmal, womit die Mitarbeiter lokal arbeiten, und zum anneren ein Tool, was iwie Änderungen identifizieren und zur Zentrale schicken muß.
    Letztgenanntes Tool bräuchteja gar kein Gui - das wäreja schoma die vollendete Lösung deiner Probleme mit dem DGV :evil: .

    Also was sehr langsames und mit extrem hohem Traffic könnteman schon basteln, wo wirklich die komplette Zentral-DB mit der Replikation durch-vergleicht.
    Will mans effizienter haben, muss man sich was listenreiches ausdenken, wie Änderungstabellen zu führen sind, und wie sich Zentrale und Replikation über diese Ännerungslisten mitnander austauschen.
    D.h. Beim Abspeichern muß man immer erst das Dataset untersuchen, und daraufhin Einträge in die Änderungstabellen machen.
    Guten MOrgen,
    da ja für mich bei der ganzen Sache auch ein gewisser Lerneffekt bei rumkommen soll werde ich die lange programmiererei in Kauf nehmen. Der Abgleich erfolgt bei mir über Transfertabellen. Eine, in die neue Datensätze angefügt werden, eine weitere in der alle Änderungen erfasst werden. Bei Programmstart werden die Daten der Transferlisten an die Zentral-DB übergeben, erst neue dann geänderte Datensätze. Das funktioniert ja sweit auch alles und zwar fehlerfrei... und soviel Schreibarbeit war das auch nicht.

    SO, ich muss jetzt erst einmal auf die Arbeit und werde mir Deine Links dann Heute Abend mal ansehen.

    Gruß
    Markus



    So, da wären wir dann mal wieder...
    Hey, die Merge ist im Endeffekt genau das was bei mir laufen soll. Meine "Transfer-Tabellen" sind im Endeffekt nichts anderes als bei denen die Transaktionstabellen. Soweit bin ich ja schon. Ich kann vorhandene Datensätze abändern oder neue hinzufügen. Das wird mir, bei meinem Programmfortschritt ja auch beim Übertragen an die Zentral-DB (Verteiler) alles richtig eingefügt. Im Augenblick scheitert es ja bei mir nur an dem Download der Daten aus dem Verteiler an die Lokal-DB. Da bekomme ich ja immer den Datentypenkonflikt im Kriterienausdruck :cursing:

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „MaThoPa1973“ ()