Da die Altanwendung so funktioniert musst du wohl oder übel genauso verfahren.
D.h., bevor der User den Satz editieren kann eben die Satzsperre setzen. Ist dies nicht möglich, kann der User gar nicht erst editieren!

Bei anderen Anwendungen mit sog. "logischen" Sperren wird ja auch nicht anders verfahren. Wenn der Vorgang (Satz, Beleg, Auftrag) gesperrt ist kann eben nicht bearbeitet werden.
Der User bekommt einen Hinweis und muss es selber eben später noch mal versuchen.

Wenn du in deiner RIA nicht ähnliche Methoden der Sperre verwendest kann es gerade hier ja zu konkurrenten Updates kommen.
Wenn der Satz frei ist und eben keine Sperre (wie auch immer realisiert)existiert können ja 2 oder mehr User diesen Satz bearbeiten und der letzte Update gewinnt!

Wenn ich mir mit .NET und einem DBDataAdapter den SQL-Update generieren lasse, wird in der Where-Klausel jedes einzelne Feld auf den vorherigen Inhalt überprüft und bei Ungleichheit der Update abgelehnt.
Ich muss nun die aktuellen Werte erneut abrufen, dem User die Änderungen ausgeben und ihn dazu veranlassen ggf. seine Änderungen zu wiederholen wenn von ihm geänderte Felder oder abhängige Felder nicht mehr den erwarteten Inhalt haben.

Gerade bei RIA's o.ä. muss man sich diesbezüglich sowieso von der alten Logik verabschieden.