Autor Beitrag
Christoph1972
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Di 07.07.09 21:31 
Hallo zusammen!

Ich hätte gerne euren Rat zum Thema „Parallelitätskonfliktvermeidung“.

Szenario: User bearbeitet einen Datensatz an Arbeitsstation A, geht zur Mittagspause und lässt die Anwendung offen. Nach der Mittagspause arbeitet er an Arbeitsstation B weiter. Nach dem Kaffee am Nachmittag wechselt er wieder zur Station A und erhält dort prompt die Message: Parallelitätsfehler 0 der 1 blablabla……

Was ist den wohl „best practise“ derartige Konflikte zu vermeiden?

Meine Idee wäre, mit einem Timer zu überwachen wann die letzte Eingabe gemacht wurde. Wenn die letzte Eingabe z.B. länger als 5min her ist, wird das MDI-Child der Application in den Hintergrund gebracht. So kann ich den User zwingen das DataSet neu zu füllen, in dem er das Child erneut aufruft.

Klar, Parallelitätskonflikte können so zwar nicht ausgeschlossen werden, aber das Risiko ließe sich so herabsetzten.

Was haltet ihr von dieser Idee?

Ein Event kann man nicht zufällig vom SQL-Server abbonieren, das die Application über Datenänderungen informiert, oder? :roll:


Gruß
Christoph
Kha
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: Di 07.07.09 23:26 
Ich bin mir nicht ganz sicher, was du mit deinen Tricksereien vor hast ;) ...
Entweder die letzten Änderungen sollen immer übernommen werden, dann nimmst du ConflictOption.OverwriteChanges. Oder der User soll die Daten noch einmal eingeben, dann rufst du beim Concurrency-Fehler RejectChangesauf und zeigst das Formular noch einmal an.

_________________
>λ=
Christoph1972 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 690
Erhaltene Danke: 16


VS2015 Pro / C# & VB.Net
BeitragVerfasst: Mi 08.07.09 06:58 
user profile iconKha hat folgendes geschrieben Zum zitierten Posting springen:
Oder der User soll die Daten noch einmal eingeben, dann rufst du beim Concurrency-Fehler RejectChangesauf und zeigst das Formular noch einmal an.


Genau das möchte ich verhindern, da die Daten von einem Messgerät kommen. Wenn die Daten einmal weg sind, dann sind sie weg. Das ist dann dann mit einem erheblichem Mehraufwand verbunden. Falls es doch mal zu einem Konflikt kommt, muss der User entscheiden, überschreiben ja oder nein.

ausblenden C#-Quelltext
1:
ConflictOption.OverwriteChanges					


Das muss ich mir mal ansehen. Ich habe mir extra eine Klasse erstellt, mit der ich mittels SQL-Command überschreiben kann. Siehe hier

Gruß
Christoph
kingdave2nd
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 54



BeitragVerfasst: Fr 17.07.09 09:35 
Hi,

ich nutze ein zusätzliches Attribut "StateRevisionCounter" (INT) in meinen Tabellen der Datenbank. Bei jedem schreibenden Zugriff zähle ich den Counter um 1 hoch. Beim laden meiner Daten steckt dieser StateRevisionCounter (vererbt über eine Base Class) in jedem Objekt drinnen. Nun kannst du in der Base Class eine Prüfung des Counter (Vergleich lokaler Counter im Speicher und Counter in der DB) vornehmen, wenn du einen Datensatz in der Datenbank aktualiseren möchtest (UPDATE). ist der Wert nicht identisch, schmeisst du eine Exception auf die du dann reagieren kannst.

Wenn du dich weiter damit beschäftigen willst, such mal unter "Optimistic Locking" und "Pessimistic Locking". Da findet man so einige Hinweise wie andere so daran gegangen sind. Es gibt wohl auch Datenbanksysteme die das nativ unterstützen, aber ich habe es aus Gründen der Kompatibilität immer selber in meinem Code gelöst.

Gruss Dave