Die firstonly-Falle

Dies ist eine Übersetzung des englischsprachingen Beitrags the firstonly trap.

Die Verwendung des Firstonly-Qualifizierer in einem X++ Select Statement kann die Ausführungsgeschwindigkeit erheblich steigern. Also warum den Qualifizierer nicht auch für update_recordset und delete_from anwenden? Das war meine Idee und so begann ich folgenden Code umzuschreiben:

ttsbegin;
select firstonly forupdate myTable where myTable.NotUniqueField == 'anyValue';
myTable.delete();
ttscommit;

nach

delete_from firstonly myTable where myTable.NotUniqueField == 'anyValue';

Leider entsprach das Resultat nicht den Erwartungen. Alle Datensätze die mit den Abfragekriterien übereinstimmten wurden gelöscht. Zuerst dache ich, delete_from firstonly leide an der gleichen Ungenauigkeit wie select firstonly und deshalb sei nicht sichergestellt, dass immer nur ein Datensatz verarbeitet würde. Aber in Wirklichkeit sieht es eher so aus, dass der Firstonly-Qualifizierer weder für update_recordset noch für delete_from implementiert wurde (auch wenn der X++ Kompiler es akzeptiert).

Andrerseits, T-SQL bietet die Möglichkeit das TOP-Schlüsselwort in Select-, Update- und auch Delete-Anweisungen zu verwenden - und warum sollte der Kompiler schlucken was keinen Sinn macht? Ich könnte mir vorstellen, dass diese Funktionalität in späteren Versionen zur Verfügung steht. Ich werden den Firstonly-Qualifizierer weiterhin gebrauchen, aber nur wenn die Where-Kriterien einen eindeutigen Datensatz referenzieren.

delete_from firstonly myTable where myTable.UniqueField == 'keyValue';
// and
update_recordset firstonly myTable setting AnyField = 'anyValue' where myTable.UniqueField == 'keyValue';

Vielleicht wird Code von heute auch in späteren AX-Versionen verwendet, wenn update_recordset und delete_from den Firstonly-Qualifizierer unterstützen. Ausserdem finde ich, dass es das Lesen des Codes ein wenig erleichtert.

Also tappt nicht auch in diese Falle ;)