Daten von einem Server auf einen anderen mit gleicher Struktur kopieren

  • VB.NET

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von Nils_Kr.

    Daten von einem Server auf einen anderen mit gleicher Struktur kopieren

    Hi,

    ich nutze die Helperklassen von @ErfinderDesRades und mit folgendem Code hole ich die Daten vom Server und befülle mein DataSet:

    VB.NET-Quellcode

    1. Dim adp2 = New DatasetAdapter(SqlClient.SqlClientFactory.Instance, constr, _
    2. Data.ConflictOption.OverwriteChanges)
    3. MyDataSet.Adapter(adp2).Register(Me).Fill()


    Gespeichert wird so:

    VB.NET-Quellcode

    1. MyDataSet.Save(Me)


    Jetzt hätte ich aber gerne, dass die Daten nicht auf den selben Server, sondern auf einen anderen mit gleicher Struktur gespeichert werden. Bis jetzt habe ich es aber weder geschafft den DataSetAdapter zu ändern, noch die Daten in ein anderes DataSet zu kopieren, welches dann einen eigenen Adapter zum anderen Server hätte.

    Mein bisheriger Ansatz:

    VB.NET-Quellcode

    1. Dim adpx = New DatasetAdapter(SqlClient.SqlClientFactory.Instance, otherstring, _
    2. Data.ConflictOption.OverwriteChanges)
    3. Dim nwDataSet As New DataSet
    4. nwDataSet.Adapter(adpx).Register(Me).Fill()
    5. nwDataSet = MyDataSet.Copy()
    6. nwDataSet.Save(Me)


    Das temporäre DataSet bekommt Daten vom Server, und das überschreiben scheint auch zu funktionieren, da die Datenmenge nach Copy() eine andere ist. Allerdings wird nichts auf den Zielserver geschrieben ?(

    PS: Ich habe leider keinen vollen Zugriff auf den Quellserver, daher kann ich die Daten nicht direkt kopieren.
    Option strict = on

    If it's stupid and it works it ain't stupid.
    @Nils_Kr
    Überprüf' doch mal nach nwDataSet = MyDataSet.Copy() mit Dim changes=nwDataset.HasChanges. Denn nur wenn es hier Änderungen gibt, wird mit nwDataSet.Save(Me) überhaupt etwas geschrieben.
    ich hab nochmal alles überprüft, wenn ich ein weiteres DataSet per Designer erstelle und die DataTables reinkopiere wird es vom Server befüllt. Wenn ich zur Laufzeit ein leeres DataSet erstelle wird es vom Server nicht befüllt, es kommt allerdings auch keine Fehlermeldung.

    Wenn ich also ein ÜbergangsDataSet im Designer erstelle, kann ich es vom Server befüllen und die Änderungen zurück schreiben. Nur die Funktion MyDataSet.Copy() funktioniert leider nicht. Dann kommt Fehler 1 "Option Strict On" lässt keine impliziten Konvertierungen von System.Data.DataSet in MyProject.TMPDataSet zu.

    Eine Möglichkeit ist wohl alle DataTables aus dem primären DataSet durchzugehen und alle Rows einzeln rüber zu kopieren. Etwas mühselig, aber sollte klappen.
    Option strict = on

    If it's stupid and it works it ain't stupid.
    Ah, also offensichtlich ein Strukturproblem des Datasets. Mir war nicht klar, das Du mit typisiertem Dataset werkelst.
    Versuch dann mal:

    VB.NET-Quellcode

    1. Dim nwDataset=New MyDataSet

    Dann hast Du eine leeres Dataset der richtigen Struktur.

    VB.NET-Quellcode

    1. nwDataSet.Adapter(adpx).Register(Me).Fill()
    2. nwDataSet = MyDataSet.Copy()
    3. nwDataSet.Save(Me)
    sollte dann funktioklappen. Alternativ kannst Du Dataset.Merge verwenden.

    us4711 schrieb:


    VB.NET-Quellcode

    1. Dim nwDataset=New MyDataSet
    2. nwDataSet.Adapter(adpx).Register(Me).Fill()
    3. nwDataSet = MyDataSet.Copy()
    4. nwDataSet.Save(Me)


    Da funken leider die Helperklassen dazwischen. Bei Adapter.register wird dann nämlich folgende Fehlermeldung geworfen: "Die BindingSource XY ist bereits fürs EventDisabling registriert.Wird versucht, dasselbe Form mehrmals zu registrieren?" Wenn ich das richtig verstehe wird mit "new MyDataSet" nicht nur die Tables selbst übernommen, sondern auch die BindingSources etc. initialisiert, wodurch dann die Funktion denkt, dass das DataSet bereits mit dem Server synchronisiert ist.

    Ganz abgesehen davon kommt bei MyDataSet.Copy() trotzem die Fehlermeldung mit Option Strict.
    Option strict = on

    If it's stupid and it works it ain't stupid.

    Vorlage schrieb:

    VB.NET-Quellcode

    1. Dim adpx = New DatasetAdapter(SqlClient.SqlClientFactory.Instance, otherstring, _
    2. Data.ConflictOption.OverwriteChanges)
    3. Dim nwDataSet As New DataSet
    4. nwDataSet.Adapter(adpx).Register(Me).Fill()
    5. nwDataSet = MyDataSet.Copy()
    6. nwDataSet.Save(Me)
    Zunächstmal solltest du nicht das Form aufs neue Dataset registrieren, wenns bereits aufs alte registriert ist. Wundert mich eiglich, dass das geht - mir war, als hätte ich sogar eine Exception dagegen eingebaut - wie dem auch sei - lass das ;)
    Dann weissichnicht, wieso du das neue Dataset erst über den neuen DatasetAdapter befüllst, nur um inne nächsten Zeile das ganze Dataset durch ein anderes - der Copy nämlich - überzubügeln.
    Und wieder wundere ich mich, dasses nicht crasht, weil dem neuen Dataset wurde doch gar kein DatasetAdapter zugeteilt.
    Bist du das mal im Einzelschritt durchgegangen - wird das wirklich anstandslos durchlaufen?

    Also für mein Gefül solltest du dem neuen Dataset den neuen DatasetAdapter zuweisen, nichts registrieren, aber saven halt.

    VB.NET-Quellcode

    1. Dim nwDataset= MyDataSet.Copy()
    2. nwDataSet.Adapter(adpx).Save(Nothing)
    Gut möglich dass das auch nicht geht, weil nwDataset ist halt nicht typisiert.
    Ausserdem weiß ich nicht, was bei .Copy mit den Änderungsverfolgungs.Informationen passiert - werden alle neuen Datensätze auf .Added gesetzt?
    Weil beim Saven werden ja nur Änderungen an die Db geschrieben, was .UnChanged ist nicht.

    Aber prüfe erstmal, ob der Code ühaupt anstandslos durhlaufen wird, oder ob das wieder son Startup-Fail ist, wo die Code-Ausführung ohne jede Meldung rausfliegt.

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

    Oben sieht man, dass es sowohl einen adp2 als auch einen adpx gibt. Sind also 2 DataSetAdapter mit 2 DataSets die jeweils auf einen eigenen Server zeigen.

    Typisierte DataSets werden problemlos geladen und Änderungen auf den Server geschrieben (bei beiden Servern), bei nicht typisierten DataSets machen die DataSetAdapter nichts, keine Fehlermeldung, keine Befüllung.

    Ich benutze jetzt übrigens einfach XML um die Anwendung außerhalb des Netzwerks testen zu können. Funktioniert prima.
    Option strict = on

    If it's stupid and it works it ain't stupid.