Dataset update nach Änderung

  • VB.NET
  • .NET (FX) 4.0

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

    Dataset update nach Änderung

    Hallo Ihrs,

    Folgendes Problem:
    In einem Dataset können neuen gebundenen Spalten NICHT hinzugefügt werden.
    Die Datenbank hat die neue Spalte bereits, jedoch das Dataset selbst hat sich nicht aktualisiert
    und somit kann die neue Spalte im Dataset nicht gebunden werden (siehe Anhang-Bild).

    Leider "lebt" das Programm sobald es draußen ist. Spalten und Ansichten können und sollen also veränderbar und nicht starr sein.
    Es muss also möglich sein, das Programm mit Spalten zu erweitern ohne das Dataset neu anlegen zu müssen.
    Das Programm hat mehrere Joins in verschiedenen Tabellen. Dieser Punkt funktioniert auch soweit.

    Gibt es also irgend eine Möglichkeit in einem Datagridview die "Datengebundene Spalten" der Datenbank aus neu zu holen?

    Das Tut von den Vier-Views habe ich mittlerweile komplett durch, jedoch muss das Dataset variabel bleiben.

    Meine Versuche mit dem Entity Framework und TableJoins zu arbeiten, sind ebenfalls in s Leere gelaufen.
    Bilder
    • Unbenannt.jpg

      116,39 kB, 625×766, 169 mal angesehen

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

    ich meine nicht zur Laufzeit des Programms selbst,

    sondern wenn man eine Version 1.1 des Programms raus bringt, das neue Felder beinhaltet, weil der "Kunde" das noch gewünscht hat.

    Gibt es sonst eine Art, wie man diese Vorgabe erfüllen kann?

    Entity Framework ist fehlgeschlagen, da bei dem Versuch mit "Model First" die Datenbank zu erstellen (benutzer MySQL wg Vorgabe) nur ein "SQL Server 2008"-Fenster aufpoppt. Beim Eingeben der MySQL Daten kommt eine Fehlermeldung und mir ist nicht bekannt wie man dieses Fenster ersetzen könnte ...

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

    ah, wenn du das Datenmodell änderst, dann muss die Datenbank (so vorhanden) geändert werden, dann das typDataset inklusive der Befüllungs-Methoden, dann die Anwendung (sowohl Code als auch Oberfläche).

    Solch ist immer sehr heikel, also mach als erstes ein Backup (inklusive Datenbank-Datei!!), zippe das und teste auch, ob das entpackte Teil auch läuft, denn auch beim Backupmachen kann man Fehler machen.

    Jo, und wenn du zuerst die DB geändert hast, dann generier dir daraus dein Dataset neu.

    Je nachdem, was geändert wurde, ist das Projekt anschließend wieder lauffähig oder eben erstmal auch nicht, oder eben auch tw. total kaputt (Form-Designer kann keine Forms anzeigen, in denen an Spalten gebunden ist, die nicht mehr existieren).
    Und diese heikle Veränderung kann auch nicht mit EF vereinfacht werden?

    Das Programm hat verschiedene Rollen inklusive Rechten, wie Projektleiter, Konstrukteur, Simulant, Administrator... und jeweils immer eine einzelne Ansicht.
    Da ist das manuelle neu anlegen umständlich.

    Nachteil: Leider sind so gut wie alle guides für das EF in C# und die Projektrichtlinie ist Visual Basic. Ebenfalls weiß ich da (noch) nicht wie man sicher join-Abfragen in eine DGV schreibt, speichert, insert, ... macht
    Nein, wenn man EF benutzt, sind Datenmodell-Änderungen genauso heikel.
    Das Datenmodell - unabhängig, in welcher Technologie umgesetzt - ist numal das Fundament einer Anwendung.
    Und nachträglich ein Fundament zu ändern ist numal heikel, weil alles annere ja drauf aufgebaut ist.

    Übrigens sollte beinem korrekten rollenbasiertes Datenmodell zur Rechteverteilung die Einführung/Änderung verschiedener Rollen wie "Projektleiter, Konstrukteur, Simulant, Administrator" keinesfalls Änderungen am Datenmodell erforderlich machen.

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

    Danke erstmal für die erleuchtenden Einwände :)

    Es werden feste Rollen sein. Die Struktur der Firma wird sich in nächster Zeit nicht ändern.

    Die Zusätzlichen Spalten sind Eigenschaften einer Komponente. Falls einem Teamleiter einfällt, dass er jetzt eine Eigenschaft noch in der Tabelle mit haben will,
    wie ... zB. Abmaße der Komponente oder ähnliches.
    Das wird später der springende Punkt sein.