In Anwendung dauerhaft aktuelle Daten aus DB anzeigen

  • VB.NET

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von EaranMaleasi.

    In Anwendung dauerhaft aktuelle Daten aus DB anzeigen

    Guten Tag,

    ich möchte in meiner Anwendung, dauerhaft aktuelle Daten anzeigen. Das heißt wenn jemand in der Anwendung ein Datensatz ändert, soll sofort im Datagridview des anderen Anwenders der Datensatz geändert werden.

    Ist dies Realisierbar?

    Hätte mir das so vorgestellt, das man über ein Backgroundworker alle 5 Sek in der Datenbank nachschaut ob ein Datensatz geändert wurde, und falls ja wird das Datagridview neu mit Daten gespeißt.

    Würde das funktionieren? oder wie macht man es sonst?

    Liebe Grüße
    Hätte mir das so vorgestellt, das man über ein Backgroundworker alle 5 Sek in der Datenbank nachschaut ob ein Datensatz geändert wurde, und falls ja wird das Datagridview neu mit Daten gespeißt.

    Das ist die falsche Herangehensweise.
    lass den Server/Datenbank eine Meldung losschicken wenn Änderungen Vorhanden sind.

    Wie stellst du die Verbindung zu DB her? TCP? Alles auf einem PC?

    Kann deine Datenbank mit, sagen wir, 2,3,4 Verbindung gleichzeitig um? Oder musst du evtl etwas davor schalten was sich um die Read/Write Zugriffe kümmert?
    Stickwort: Deadlock
    Nachdem ein User einen Datensatz angelegt/geändert hast, schickst du eine Meldung los über die gleiche Schnittstelle wie deine Clienten an die Daten kommen, darauf warten die Clienten und holen sich darauf hin die neuen sätze
    Wenn

    Kevin12345 schrieb:

    sofort im Datagridview des anderen Anwenders der Datensatz geändert
    wird, was würde passieren, wenn Benutzer 1 Murks in die DB einträgt und diese commitet und sich das dann bei Benutzer 2-5, die gerade dabei sind, sinnvolle Daten einzutragen, festsetzt, weil es ihnen aufgezwungen wird? Die werden sich freuen, da die dann von vorne anfangen müssen …
    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.
    Einen Datenbank-Trigger aufsetzen, der auf das Ändern bestimmter Felder reagiert.
    Dieser schreibt einen Timestamp in eine Hilfstabelle, die nur aus einem Record besteht (ggf. mit Spalten für verschiedene Tabellen).
    Dieses Feld kann per Timer gepollt werden.
    Wenn der zuvor gepollte Timestamp älter ist, kannst du den Update des DGV anstoßen.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --
    @EaranMaleasi: Wie lässt sich der Wunsch des TE

    Kevin12345 schrieb:

    wenn jemand in der Anwendung ein Datensatz ändert, soll sofort im Datagridview des anderen Anwenders der Datensatz geändert werden.

    mit

    EaranMaleasi schrieb:

    Dafür gibt es in DBMS Sperren.
    vereinbaren? Er will ja, dass das DGV der anderer User unverzüglich abgeändert wird. Und da hatte ich nach dem Sinn gefragt. Dass man das verhindern kann, ist mir durchaus bewusst.
    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.
    Das scheint mir selbstverständlich, dasses in eim Mehrbenutzer-System sinnvoll und wünschenswert ist, dass alle Benutzer immer auffm aktuellen Stand sind.
    Schwierig ist die Umsetzung dessen.
    Das Problem ist wellknown, etwa unter dem Begriff "DbConcurrency".
    Eine Patentlösung gibt es nicht, und jede Lösung hat Vor- und Nach-teile.

    Nur mal 2 Strategien erwähnt:
    • Last-In-Wins
      Wenn 2 User denselben Datensatz bearbeiten überschreibt der, der als letztes speichert die gemachten Eingaben seines "Konkurrenten".
      Vorteil: Einfach zu implementieren, Nachteil: Der erste User merkt oft nichtmal, dass seine Eingabe nicht wirksam wird - und dassis ärgerlich bis sogar gefährlich
    • Pessimistic Lock
      Zum Bearbeiten eines Datensatzes muss der User in einen besonderen Bearbeitungs-Modus gehen, in dem er für die Dauer seiner Bearbeitung exklusive Schreibrechte auf den Datensatz erhält.
      Vorteil: Was man bearbeitet kommt auch inne Db an, ausserdem ist (sinnlose) Doppel-Arbeit ausgeschlossen. Nachteil: Sehr aufwändig zu coden, vergleichsweise umständlich zu bedienen.
    "DBMS-Sperren" gibts viele - manche zum Verhindern, dass Murks eingetragen wird, andere befassen sich mit Zugriffsrechten - das hat ja mit DbConcurrency erstma nix zu tun.
    Und natürlich gibts auch DBMS-Unterstützung für pessimistisches Locking.


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

    Kevin12345 schrieb:

    dauerhaft aktuelle Daten anzeigen

    Sollen an diesen Client Arbeitsplätzen denn überhaupt Änderungen vorgenommen werden können? Wenn nicht, ist die Lösung doch trivial.
    Ansonsten:

    ErfinderDesRades schrieb:

    Eine Patentlösung gibt es nicht, und jede Lösung hat Vor- und Nach-teile.

    ErfinderDesRades schrieb:

    Das scheint mir selbstverständlich, dasses in eim Mehrbenutzer-System sinnvoll und wünschenswert ist, dass alle Benutzer immer auffm aktuellen Stand sind.
    Schwierig ist die Umsetzung dessen.
    Das Problem ist wellknown, etwa unter dem Begriff "DbConcurrency".
    Eine Patentlösung gibt es nicht, und jede Lösung hat Vor- und Nach-teile.

    Nur mal 2 Strategien erwähnt:
    • Last-In-Wins
      Wenn 2 User denselben Datensatz bearbeiten überschreibt der, der als letztes speichert die gemachten Eingaben seines "Konkurrenten".
      Vorteil: Einfach zu implementieren, Nachteil: Der erste User merkt oft nichtmal, dass seine Eingabe nicht wirksam wird - und dassis ärgerlich bis sogar gefährlich
    • Pessimistic Lock
      Zum Bearbeiten eines Datensatzes muss der User in einen besonderen Bearbeitungs-Modus gehen, in dem er für die Dauer seiner Bearbeitung exklusive Schreibrechte auf den Datensatz erhält.
      Vorteil: Was man bearbeitet kommt auch inne Db an, ausserdem ist (sinnlose) Doppel-Arbeit ausgeschlossen. Nachteil: Sehr aufwändig zu coden, vergleichsweise umständlich zu bedienen.
    "DBMS-Sperren" gibts viele - manche zum Verhindern, dass Murks eingetragen wird, andere befassen sich mit Zugriffsrechten - das hat ja mit DbConcurrency erstma nix zu tun.
    Und natürlich gibts auch DBMS-Unterstützung für pessimistisches Locking.




    Ich bin eher Fan von First in Wins (Nur um weitere Methoden hier im Thread aufzuzählen):

    An jeder Datenbank Entität ist ein Feld "Version" die bei jeder Änderung inkrementiert wird, möchte nun der zweite Benutzer seine Änderung speichern kann er darauf hingewiesen werden das die Datenbank schon Version 2 der Entität besitzt während er Version 1 bearbeitet hat.
    Jo - "First-In-Wins" ist vlt die bessere, v.a. allgemeinere Bezeichnung dessen, was ich als "Pessimistic Lock" ausgeführt habe.
    "Mein" FirstInWins unterbindet bereits den Bearbeitungs-Modus, wenn ein anderer bereits bearbeitet.
    "Dein" FirstInWins lässt Doppel-Bearbeitungen durchaus zu, was dann natürlich ärgerlich ist für den "Verlierer".

    Edit: Übrigens finde ich nicht das eine besser als das andere. Wenn Doppel-Bearbeitungen nur selten vorkommen, ist das mit dem Extra-Bearbeitungsmodus oversized und umständlich.
    Lass doch alle 10 Tage mal einen als "Verlierer" sich ärgern - wenn man dafür Änderungen viel einfacher eintragen kann, ohne jedes mal umständlich in den Bearbeitungsmodus wechseln zu müssen.

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

    MySQL kann es gleich mal in 2 Varianten:
    dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html

    Daher ist anzunehmen, dass Orcale und MSSQL das auch können.

    Edit: kurze suchen im Internet suggerieren, dass Oracle ziemlich sicher, und MSSQL mit den richtigen Umständen ebenfalls in der Lage sind Row-Level-locking durchzuführen.

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