Pedde Geschrieben 30. April 2008 Teilen Geschrieben 30. April 2008 Hallo, ich habe hier eine MS SQL Server 2005 DB und folgende Problemstellung. Wenn ich einen Datensatz als "In Bearbeitung" markiere (extra Spalte in Tabelle), dann möchte ich, dass alle Clients (Programme) diesen Status des Datensatzes dann auch darstellen ohne immer wieder die DB zyklisch abfragen zu müssen. Nun meine Frage: Geht sowas, dass der SQL Server ein Event aussendet, das da sagt "Ich habe mich geändert, bitte Daten erneut abfragen!" oder geht sowas nur über zyklische Abfragen? Gruß, Pedde Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 30. April 2008 Teilen Geschrieben 30. April 2008 Mal davon abgesehen, dass das extra markieren eines Datensatzes als "In Bearbeitung" schon ein Designfehler an sich ist: Nein deine Anforderung wird sich so einfach wohl nicht umsetzen lassen. Eine Möglichkeit wäre die Verwendung von messaging aus der Datenbank heraus, aber ich weiß weder ob MSSQL das bietet noch welche Aufwände das verursachen würde. Dim Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Pedde Geschrieben 30. April 2008 Autor Teilen Geschrieben 30. April 2008 Mal davon abgesehen, dass das extra markieren eines Datensatzes als "In Bearbeitung" schon ein Designfehler an sich ist... Warum sollte das ein Designfehler sein, wenn ich es nicht erlauben DARF mehreren Benutzern denselben Datensatz gleichzeitig zu bearbeiten??? -- Pedde Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 30. April 2008 Teilen Geschrieben 30. April 2008 Dafür gibt es Datensatzsperren, die die Datenbank extra dafür bereitstellt. Man macht dann einen SELECT ... FOR UPDATE und sperrt für die eigene Session den Datensatz. Und zwar 100%ig sicher. Des weiteren hast Du keinen Datenmüll in den Tabellen stehen. Wenn z.B. das Programm abstürzt, denn dann wäre noch der Eintrag in der Tabelle, dass der Satz in Bearbeitung ist, was natürlich nicht mehr stimmt und dazu führt, dass Du einen Job brauchst der das ganze regelmäßig wieder aufräumt. Gleiches gilt beim Einspielen von Backups. Dort sind dann evtl. Einträge in den Tabellen die nicht die Realität wiederspiegeln. Von dem zusätzlichen Aufwand zuerst die Locktabelle abzufragen, einen Eintrag zu machen und dann die Daten zu selektieren gar nicht erst zu sprechen. Daher gilt wieder der alte Leitspruch: Programmiere nichts nach was die DB bereits bietet, denn Du wirst immer schlechter und langsamer sein. Dim Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Ratzinger Geschrieben 30. April 2008 Teilen Geschrieben 30. April 2008 Warum sollte das ein Designfehler sein, wenn ich es nicht erlauben DARF mehreren Benutzern denselben Datensatz gleichzeitig zu bearbeiten??? -- Pedde Du solltest dich mehr mit der Funktion einer Datenbank im Allgemeinen beschäftigen Sperrmechanismen bietet jede Datenbank und gehört zu den Grundvorraussetzungen eines jeden DBMS Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Goos Geschrieben 5. Mai 2008 Teilen Geschrieben 5. Mai 2008 Abgesehen davon, dass du das echt nicht so machen solltest, kannst du zu dem Thema in den BOL unter "Query Notifications" nachschlagen. Das bietet mit gewissen Einschraenkungen die von dir geforderten Events. Natuerlich muss es dann in jede Clientapplikation entsprechend eingebaut werden. Goos Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.