Abgesichertes Editieren von DataSets und multiple Einträge mit .Fill

  • VB.NET

Es gibt 4 Antworten in diesem Thema. Der letzte Beitrag () ist von Haudruferzappeltnoch.

    Abgesichertes Editieren von DataSets und multiple Einträge mit .Fill

    Hallo,

    also mit folgendem Code habe ich eine Datenquelle und ein DataGridView miteinander verknüpft. Fill, Update und Änderungen machen funktioniert alles. Ich möchte aber, das Änderungen nicht generell übernommen werden. Dafür also die CheckBox als Dummy-Absicherung. Trotzdem sollen im DGV jederzeit Änderungen gemacht werden können.
    Die Logik ist, dass nur die Datenquelle keine Änderungen übernimmt, die getätigt wurden während der Haken nicht gesetzt war. Ist diese Lösung daher sinnvoll?

    VB.NET-Quellcode

    1. Option Strict On
    2. Public Class Form1
    3. Private da As New SqlDataAdapter
    4. Private a As SqlCommandBuilder
    5. Private Sub Form1_Load(sender As Object, e As EventArgs) Handles Me.Load
    6. Dim DBZ As New DBZugriff("Select * from DasIstEinTest", DBZugriff.Server.Servername, DBZugriff.DataBase.Databasename)
    7. Dim cmd = DBZ.CreateCommand
    8. da.SelectCommand = cmd
    9. a = New SqlCommandBuilder(da)
    10. End Sub
    11. Private Sub btnSave_Click(sender As Object, e As EventArgs) Handles btnSave.Click
    12. If chkEdit.Checked Then
    13. DS1.DasIstEinTest.AcceptChanges()
    14. da.Update(DS1, "DasIstEinTest")
    15. Else
    16. If MessageBox.Show(Me, "Änderungsmodus war inaktiv", "Änderungsmodus muss vor den Änderungen freigeschaltet werden, Änderungen zurücksetzen?", MessageBoxButtons.YesNo) = DialogResult.Yes Then
    17. DS1.DasIstEinTest.RejectChanges()
    18. End If
    19. End If
    20. End Sub
    21. Private Sub btnLoad_Click(sender As Object, e As EventArgs) Handles btnLoad.Click
    22. da.Fill(DS1, "DasIstEinTest")
    23. End Sub
    24. Private Sub chkEdit_CheckedChanged(sender As Object, e As EventArgs) Handles chkEdit.CheckedChanged
    25. If Not chkEdit.Checked Then DS1.DasIstEinTest.RejectChanges()
    26. End Sub
    27. End Class

    ------------------------
    Außerdem ist mir aufgefallen, dass .Fill in diesem Fall keine Multi-Einträge erzeugt. Ich habe einen Primärschlüssel auf der DasIstEinTest Tabelle, was ich sonst nie benutzt habe, ich schätze es liegt daran. (Musste sonst die Tabelle vor dem Fill immer Clearen)
    Was passiert da in diesem Fall genau? Werden aufgrund des Primärschlüssels die Einträge durch ein erneutes Fill überschrieben oder werden die Einträge geblockt? Wenn sich die Datenquelle ändert, dann bekomme ich bei erneutem Fill auch die Änderungen mit. Fill ich stattdessen nur mit einer Teilmenge, behalte ich trotzdem alle Einträge. Es sieht aus als überschreibt er nur die Zeilen, die den gleichen PK haben? In MSSQL wird stattdessen der Eintrag ja eigentlich geblockt, wenn ein PK bereits vorhanden ist.

    Desweiteren geht Fill offenbar an RejectChanges vorbei. RejectChanges kann Änderungen vor dem Fill zurücksetzen aber der Fill bleibt 8|

    Viele Grüße

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Haudruferzappeltnoch“ ()

    Haudruferzappeltnoch schrieb:

    Ich möchte aber, das Änderungen nicht generell übernommen werden. Dafür also die CheckBox als Dummy-Absicherung. Trotzdem sollen im DGV jederzeit Änderungen gemacht werden können.
    Was denn nu? Sollen Änderungen gemacht werden dürfen oder nicht.
    Wenn nicht, setze DGV.Readonly=True
    Ans Dataset musste dafür garnet ran.
    Für keine gute Idee halte ich, dass im DGV was eingetragen werden kann, wo von vornherein klar ist, dasses nicht übernommen werden darf.

    ErfinderDesRades schrieb:


    Für keine gute Idee halte ich, dass im DGV was eingetragen werden kann, wo von vornherein klar ist, dasses nicht übernommen werden darf.


    Hm, sehe den Punkt. Einträge ausprobieren wollte ich gerne möglich haben. Was wenn es nicht unbedingt von vornherein klar ist, ob es übernommen werden darf?
    Aber ja ans DataSet nicht rangehen: ich könnte auch die BindingSource solange kappen.
    Dann stellt sich die Frage, wodurch entschieden wird, ob die Daten korrekt sind oder nicht, also übernommen werden sollen?
    Ist das abhängig vom User?
    Vom Programmfluss?
    Vom Wetter?
    Geworfenen Würfeln?
    Welchen Bewandnis hat es, vorher schon Einträge zu machen?

    Ich hab in meinen Programmen zu Programmende nochmal dem User die Chance gegeben zu entscheiden, ob gespeichert werden soll oder nicht. Notfalls kann er sich die Änderungen auch nochmal (in Rohform) anschauen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.