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 …

@VaporiZed Dafür gibt es in DBMS Sperren.

Gelöschter Benutzer schrieb:

schickst du eine Meldung los über die gleiche Schnittstelle wie deine Clienten an die Daten kommen

Ich tippe auf eine direkte Datenbankanbindung. Die Schnittstelle müsste erst noch implementiert werden.

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.

@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.

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.

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.

Kannst du den speziell einen Eintrag locken? - Dachte das wäre nur Tabellenweit möglich (TableLocks).

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.