[...], zwei Fälle:
- Transaktionssichere Tabelle
- nicht transaktionssichere Tabelle
Otto ändert den Eintrag zu Willis-Phone-Number. Fast zur gleichen Zeit editiert Erwin den Eintrag zu Willis-Phone-Number.
Was passiert im Fall 'Erwin macht den letzten Klick'
Dann hast Du den Salat, Otto wird unglücklich, hier böte sich:
- eine Ablehnung der Aktualisierung Edwins an
- alternativ Aktualisierung nur im "single dataset view", wobei eine entsprechende Meldung "Datensatz wird gerade (von Otto) bearbeitet" hochkommen sollte
- Erwins Eintrag ist dominant, weil nach dem Transaktionskonzept die Engine schön und brav wartet, bis Otto fertig ist
- Otto ist zwar schneller fertig, aber Erwin kommt später und überschreibt.
Ist derselbe Fall. Oder?
Hmm. Was gibts denn nun wirklich zu beachten? Transaktionssichere Tabellen?
Tabellen sind nicht "transaktionssicher", sondern gesperrt oder nicht gesperrt (hier würde sich eine handgemachte Sperre auf Datensatzebene anbieten). Transaktionen spielen hier m.E. keine Rolle bzw. sollten keine Rolle spielen.
Richtig giftig wird es, wenn Du combo boxen hast, die auf andere Entitäten verweisen, die selbst gerade editiert werden.
Hoffe mal, dass Du sowas nicht hast, aber es ist kein Fehler rechtzeitig bestimmte Überlegungen anzustellen (Datensatzowner-Konzepte, check out-Konzepte, "Konzepte über Konzepte" ;).
Viel Spass!