dauerhafter Live Zugriff auf SQL Datenbank

  • VB.NET

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

    dauerhafter Live Zugriff auf SQL Datenbank

    Hallo, Zusammen,

    ich habe ein kleines Problem.

    Ich habe in meinem vb.net Projekt einen Timer der in einem Interval von 100 immer wieder eine SQL abfrage ausführt.
    Dies ist natürlich sehr leistungsfressend und nicht die schickste Variante.

    Welche Möglichkeiten habe ich, damit ich quasi einen direkten Livezugriff auf die Datenbank habe und immer einen aktuellen Wert aus der Datenbank habe.

    um es vielleicht etwas genauer zu beschreiben.

    Es handelt sich um ein Steuerungsprogramm in dem Mitarbeiter sich zur Pause stechen können. (Hauptsächlich um sich einen Kaffee zu holen oder um eine rauchen zu gehen)
    der Mitarbeiter hat einen Button um "in Pause zu gehen" und einen um wieder zurück zu kommen.
    das Ganze ist immer auf eine bestimmte Anzahl an freien Pausenplätzen begrenzt.
    In der Datenbank wird jetzt quasi der Mitarbeiter eingetragen, sobald er in Pause geht und wieder ausgetragen, wenn er zurück ist.
    Die Mitarbeiter sehen wieviel Pausen gleichzeitig möglich sind und wieviel freie Plätze noch zur Verfügung stehen.

    Ich hoffe man versteht was ich meine und es hat jemand eine Idee wie ich das ganze ohne Timerabfrage hinbekomme.

    Exe schrieb:

    Welche Möglichkeiten habe ich, damit ich quasi einen direkten Livezugriff auf die Datenbank habe und immer einen aktuellen Wert aus der Datenbank habe.
    Dafür brauchst du doch kein 100ms-Intervall, da reichen 5 oder 10 Sekunden.

    [OffTopic]
    Ich bin froh, dass ich nicht in so einem Überwachungs-Laden arbeiten muss.
    [/OffTopic]
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Also sowas wie einen dauerhaften Einblick gibt es nicht. Du kannst bestenfalls die Verbindung dauerhaft geöffnet lassen, dadurch erhältst du aber noch keine Aktualisierung.
    Damit man eine Änderung der Daten sehen kann, muss immer eine neue Abfrage laufen.

    Dein Programm kann ja wohl selbst die paar Stempelungen temporär zwischenspeichern. Dann kannst du die Zugriffe weiter auseinanderschieben.
    Wenn du gar keinen Timer nutzen willst, kannst auch einfach nach einer bestimmten Buchungsanzahl aktualisieren.

    Also ich glaube es gibt Datenbanken, die Kontostände verwalten können, obwohl tausende von Terminals quasi gleichzeitig Geld abheben können. Und das ohne Timer bei der Bank.(man verzeihe mir meinen Sarkasmus) Die Technologie heißt Transaktionen. Eine der simplen Strategien ist z.B. Update freie_Plätze -1 where freie_Plätze = 7 . Das geht dann schief, wenn andere Prozesse die Anzahl der freien Plätze zwischenzeitlich geändert haben. Dann weißt du, du musst die Anzahl der freien Plätze neu abfragen.

    Eine andere komplexere Möglichkeit wäre dass du dir eine Art Middleware mit API für die Anfragen und WebSocket für Updates schreibst, welche auf einem Server läuft.
    Erforderlich dafür wäre allerdings ein zentraler Server.

    Der Ablauf wäre:
    - API Request von beliebigen Endpunkt
    - Die Middleware schreibt die Datenbank-Einträge und fragt gleichzeitig die freien Pausenplätze ab
    - Diese übermittelt diese dann an den WebSocket-Endpunkt, welcher die neuen Daten als Update an alle Clients schickt, welche dann das Update empfangen und darstellen
    Am besten wäre dies über NodeJS realisierbar, wobei dir ChatGPT ganz einfach helfen kann, wenn du keine Erfahrung damit hast.
    Alternativ kannst du auch nur den Websocket-Server über Node machen und den API-Endpunkt in einer beliebigen Sprache, welcher dann nur als WebSocket-Client die Updates über den Server an die Clients verteilt.

    Somit hast du immer Live die Daten und erhälst Updates sobald sich was ändert.
    Außerdem machst du so keine unnötigen Datenabfragen, was die Datenbank sehr entlastet und hoch skalierbar auf viele tausend Clients

    Die Frage ist, ob dies in deinem Fall überhaupt den Aufwand rechtfertig.

    Bei uns habe ich das etwas pragmatischer gelöst.

    Und zwar habe ich den FileWatcher dazu benutzt. In einem Netzwerkordner erstelle ich bei jeder Änderung eine Datei. Der Filewatcher auf den Clients reagiert Resourcenschonend Eventgesteuert auf die neue Datei. Dann lese diese die Änderungen der SQL Tabellen aus und aktualisieren die Anzeigen.

    Dass erkennen der neuen Datei erfolgt unter 1 Sec Reaktionszeit und brauche dennoch keinen Timer.

    @Coldfire

    Coldfire schrieb:

    Eine der simplen Strategien ist z.B. Update freie_Plätze -1 where freie_Plätze = 7 . Das geht dann schief, wenn andere Prozesse die Anzahl der freien Plätze zwischenzeitlich geändert haben. Dann weißt du, du musst die Anzahl der freien Plätze neu abfragen.


    Er will ja scheinbar Live-Daten haben ohne dass erst nach dem Klick angezeigt wird ob doch noch einer frei ist oder falls nicht die Fehlermeldung.

    Außerdem sind das ja nur andere Vorgehensweisen.

    Warum denn so umständlich und ressourcenraubend.
    Beim Einstempeln passiert doch schon eine SQL-Abfrage. Also da auch gleich abfragen wieviel "Restpausenplätze" zur Verfügung stehen.

    Wären also nur 3 Plätze verfügbar, es wollen aber 4 Einstempeln, dann bekommt der vierte eine "Absage" .
    Liebe Grüße
    Roland Berghöfer

    Meine aktuellen und kostenlos verwendbaren Tools (mit VB.NET erstellt): freeremarkabletools.com | priconman.com | SimpleCalendar | AudibleTouch | BOComponent.com | bonit.at

    Manchmal will man aber bereits vor dem Klick am Bildschirm sehen, ob sich der Klick "lohnen" wird oder nicht.

    Also bereits ein grün leuchtenter Monitor wenn noch was frei ist, und rot wenn nichts frei ist.
    Das sehe ich dann auch aus der Ferne iund muss nicht erst bis zum Gerär gehen und dort den Button klicken....

    Der flotte Johann schrieb:

    Manchmal will man aber bereits vor dem Klick am Bildschirm sehen, ob sich der Klick "lohnen" wird oder nicht.
    Jo, aber diese Aktualisierung findet doch beim Klick des Vorgängers statt.
    Wenn keiner klickt -> keine Änderung. Das heißt man weiß immer vor dem Klick, obs geht oder nicht geht. Deswegen einfach in der Software regeln, nicht in der DB.

    Das Problem hörte sich für mich so an als würde die DB die einzige Software-Instanz sein, in denen die Daten vorgehalten werden, was natürlich überhaupt keinen Sinn macht.
    Was ich mir noch denken könnte: Die Software, die die Klicks steuert ist unabhängig von der Software für die Anzeige, damit käme man z.b. in so ein Schlamassel.

    Vollzitat des direkten Vorposts an dieser Stelle entfernt ~VaporiZed

    Dies würde nur funktionieren, wenn es quasi nur ein Terminal gibt. Nimmt man jetzt aber mehrere verteilte, dann Updated es ja immernur das wo man grade stempelt.

    Und an die anderen:
    Wenn es jetzt anzeigt, dass nix mehr frei ist und es wird nicht geupdated ohne zu klicken, dann geht ja auch keiner hin und versucht es.

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

    ManuelSoftware schrieb:

    Dies würde nur funktionieren, wenn es quasi nur ein Terminal gibt
    Das stimmt nicht. Ein Abgleich muss natürlich da sein, das muss aber nicht die Datenbank übernehmen, lass es meinetwegen eine separate Datei sein, da gibt viele Möglichkeiten.
    Also an sich macht die Datenbank ja den Abgleich wie schon viele Leute geschrieben haben, das ist im Normalfall ja nicht problematisch. Ist nur die Frage, ob die Software das hier einfach nicht selbst speichert oder die Änderungen gar nicht tätigt.

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

    Haudruferzappeltnoch schrieb:

    Ein Abgleich muss natürlich da sein

    Das mein ich doch ;)

    Das war bezogen auf:

    Haudruferzappeltnoch schrieb:

    Jo, aber diese Aktualisierung findet doch beim Klick des Vorgängers statt.
    Wenn keiner klickt -> keine Änderung. Das heißt man weiß immer vor dem Klick, obs geht oder nicht geht.

    Eine andere Möglichkeit wäre "Filesystemwatcher".
    Ich habe eine Kalenderanwendung die auch im Netzwerk läuft. Aber ich verwende eine Access Datenbank (.mdb).
    Sobald der Filesystemwatcher meldet, dass sich die Datenbankdatei verändert hat, warte ich ein paar Sekunden und aktualisiere dann die Kalenderansicht auf den Clients.

    Vielleicht ist das eine Option?
    Liebe Grüße
    Roland Berghöfer

    Meine aktuellen und kostenlos verwendbaren Tools (mit VB.NET erstellt): freeremarkabletools.com | priconman.com | SimpleCalendar | AudibleTouch | BOComponent.com | bonit.at

    dive26 schrieb:

    Sobald der Filesystemwatcher meldet, dass sich die Datenbankdatei verändert hat, warte ich ein paar Sekunden und aktualisiere dann die Kalenderansicht auf den Clients
    Aber anscheinend will er ja 100ms-Genauigkeit.
    Das verstehe ich zwar nicht, weil für eine manuelle Pausenbuchung ist das absolut überzogen.
    Ein Wimpernschlag ist länger ;)

    Aber wir beschäftigen uns hier mit allen möglichen Vorschlägen und @Exe reagiert schon seit einer Woche nicht mehr.
    So groß kann sein Interesse an einer Lösung also nicht mehr sein.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Erst mal vielen Dank an alle für die vielen Vorschläge.

    Und Sorry das ich mich nicht so lange gemeldet habe.
    Ein anderes Projekt hatte jetzt Vorrang.

    Die Filewatcher Klasse nutze ich gerade auch im gleichen Projekt, aber für eine andere Funktion.
    Diese muss demnächst aber abdanken, da unsere Sicherheitssoftware diese Klasse als schädlich betrachtet. (Lösung dafür ist aber schon vorhanden)
    Aus Diesen Grund würde die Klasse auch nicht bei der Aktualisierung der Pausen in Frage kommen.

    Meine aktuelle Lösung sieht jetzt wie folgendermaßen aus.

    die Aktualisierung der Ansicht erfolgt jetzt nur alle 2 Sekunden.
    Sobald jemand (auch mehrere Mitarbeiter) auf den Button klickt wird eine Progressbar eingeblendet.
    Diese Progress bar wird unterschiedlich schnell mit Hilfe von Random gefüllt (zwischen 1 und 5 Sekunden)
    Nachdem die Zeit abgelaufen ist wird eine Überprüfung/Aktualisierung der Daten vorgenommen.
    Sollten dann keine Pausen mehr verfügbar sein wird der Benutzer über eine MSGBOX benachrichtig, dass er es später nochmal versuchen soll.

    Ich hätte die Progressbar auch weglassen können, aber unsere Mitarbeiter haben gerne etwas Visuelles.
    Genauso ist es, wenn alle Pausen belegt sind, dann ist der Button als Enable=False eingestellt und man erkennt sofort das keine Pausen mehr verfügbar sind.

    Leider gibt es jetzt eine andere Herausforderung.
    Jedes mal (alle 2 Sekunden) wenn die Daten aktualisiert werden, ruckelt mein Programm.
    An sich ist das nicht schlimm.
    Da ich aber noch andere Sachen in diesem Projekt für verschiedene Teams realisiere (hauptsächlich das erfassen von Daten), ruckeln auch alle anderen Userformen. kann ich das Ganze irgendwie umgehen?

    Es gibt ja auch den Backgroundworker.
    Kann ich die Aktualisierung der Daten in diesen dort einfach "reinschmeißen"?
    Habe mich damit noch nicht beschäftigt.
    Oder gäbe es noch adere Varianten, dass jede Userform "für sich" läuft und nicht von andere "beeinträchtigt" wird?