Alte MS
SQL Versionen (wahrscheinlich noch älter als die genannte) sind nicht unbedingt geeignet. Wegen fehlendem Rowlevel locking usw..
Je neuer die
SQL Server Version, desto besser.
Solche alten MS
SQL ohne solche Fähigkeiten braut man heutzutage nicht mehr berücksichtigen.
Ich denke alle Version < 2008 wird man praktisch nichts mehr "in the Wild" antreffen. Wir sperren mittlerweile alles < 2005 aktiv aus (Meldung Programmstart).
Gut hier ist es ja 2012. Hab neulich noch eine Seite gesehen (MS), die das Sperrverhalten für die Versionen 2005-2012 zusammengefasst beschrieb.
Daraus leite ich ab, dass es innerhalb dieser Versionen weitgehend ähnlich ist
und
danach (>2012) weitere Verbesserungen kamen.
Kann natürlich sein, dass die Seite auch einfach älter war, ich verfolge das nicht aktiv bei MS.
"ein Sperren des Datensatzes würde ich nicht.."
Sehe ich auch so, (unnötige) Sperren engen das System ein, vermutlich irgendwie exponentiell oder so. Also wäre optimistic locking angesagt. Sprich wenn's mal "knallt" gibt's eine nette Meldung, die Eingaben sind futsch, der User bekommt sofort ne Info und muss nacharbeiten. Hier ist es dann eine Frage des Programmaufwandes, elegant abzufangen und geänderte Werte zu retten usw.
Hab mal irgendwo in uralten Dot Net Komponenten die generierten DML Commandos von V Studio gesehen, wo die where clause aus der Nennung sämtlicher Felder bestand. Fand ich sehr witzig, dachte zuerst, der hat den PK nicht gefunden, aber im Grunde ist es ein einfacher clientseitiger Schutzmechnismus für optimistic locking.
Grundsätzlich könnte man Sperrprobleme mit sowas wie Kontingenten auf fachlicher Ebene regulieren, sehr einfach und unintelligent, aber ziemlich sicher. Jeder (angemeldete) User bekommt einen Range von Daten, die nur er bearbeiten darf/kann. Das passt sicher nicht für alle Workflows, aber oft reicht es.