“Wutschen und Wedeln” Teil 2: Zauberduell SETCURRENTKEY() vs. TableView

Am 14. Juli ist es so weit. Das große Finale der achtteiligen Verfilmung eines Siebenteilers kommt in die Kinos - in 3D! Zauberstäbe, Fabelwesen und nicht zuletzt “Sie wissen schon wer” fliegen durch den Saal. Eine recht plastische Angelegenheit wenn man vor Schreck sein Popcorn im Saal verteilt…

Zum warm werden

Plastisch soll auch der zweite Teil zum Sortieren und Filtern sein. Wobei, es geht hier primär um ersteres, also das Sortieren. Mit von der Partie ist wieder meine Sortiertabelle „My Sorting“. Unten ist auch das Design inkl. Schlüssel zu sehen. Wichtig ist, dass der Schlüssel „Code 2“ auf dem SQL Server nicht vorhanden, also MaintainSQLIndex nicht aktiviert ist. Bitte merken, wichtig!

Allgemein ist bekannt, dass man beim Betrieb der Datenbank auf dem SQL Server definieren kann, ob ein expliziter Index angelegt werden soll oder nicht. In letzterem Fall wird der SQL Server zwar, sofern angefordert, danach sortieren, aber nicht über den Index, was ggf. etwas weniger schnell ist. Meine Tabelle bzw. die definierten Schlüssel sehen im SQL Server Management Studio folgendermaßen aus:

Schlüssel 0 „Code 1,Int“ und Schlüssel 2 „Code 2,Code 3,Code 1,Int“, der, wie in Dynamics NAV üblich, noch den Primärschlüssel (0) am Ende enthält. Key 1 ist wie erwähnt nicht als Index vorhanden.

Einfache Zauber – Erwarte das unerwartete

Gelegentlich, und ich spreche hier aus eigener leidlicher Erfahrung, sollte man sich erinnern, dass Windows und so gut wie alle darauf laufenden Programme eine Hilfe haben, auch Dynamics NAV - Stichwort F1! Und wenn man so gelangweilt durch die Themen zappt, und bei SETCURRENTKEY angelangt ist, dann fällt einem folgendes auf:

Klar werden Sie sagen, das weiß ich! Ich auch, kann ich Ihnen sagen. Aber, da steht außerdem noch folgendes:

“Bei der Suche nach einem passenden Schlüssel nutzt C/SIDE das erste Auftreten der angeforderten Felder”. Ok, das ist auch noch recht plausibel. Wichtig ist hier aber zu wissen, dass deaktivierte Schlüssel eine geringere Priorität genießen. Ein SETCURRENTKEY(“Code 2”) auf obige Tabelle, selektiert den Schlüssel “Code 2,Code 3” und nicht etwa “Code 2”. Das geschieht aus Performancegründen, da der SQL Server dann nicht mehr On-the-fly sortieren muss (es existiert ja kein Index für “Code 2,Code 3”) sondern den Index für Schlüssel 2 nutzen kann.

Und damit haben wir auch gleich die Magie hinter dem zweiten Satz beleuchtet: “Wenn das angegebene Feld der erste Teil eines zusammengesetzten Schlüssels ist, dann mag der ausgewählte Schlüssel nicht der erwartete sein”. Da spätestens nach obigem Hinweis auf einen deaktivierten Index (MaintainSQLIndex=No) klar ist, was in aktuellen Versionen die Phrase “may not be the key that you expect” bedeutet, heißt das aber nicht, dass sich nicht in zukünftigen Versionen oder Hotfixes dieses Verhalten wieder ändert. Sofern nicht explizit erwähnt, wird aber obiges Statement korrekt bleiben: Erwarte das Unerwartete

Es ist übrigens möglich, speziell den Schlüssel 1 zu selektieren. Dazu ist es aber notwendig, obige Aussage zu umgehen. Fordern Sie einfach einen eindeutigen Schlüssel/Index an, so dass kein Missverständnis entstehen kann: SETCURRENTKEY(“Code 2”,”Code 1”). Damit wird Schlüssel 1 selektiert, da dieser, auch wenn auf dem SQL Server nicht als Index vorhanden, doch zusätzlich noch aus den Primärschlüsselfeldern bestehen würde. Denn es mag ja sein, dass Ihre Programmlogik genau diese Reihenfolge das voraussetzt.

Anspruchsvolle Zauber

Klingt schon ziemlich “magisch". Haben Sie Ihren Zauberstab noch griffbereit? Es geht weiter mit Pages, Forms und Reports. Dort ist das Verhalten analog zu SETCURRENTKEY:

Wird per SourceTableView oder für Reports DataItemTableView eine Sortierung nach “Code 2” angefordert, dann ergibt sich das gleiche Bild, denn aufgrund des für den SQL Server deaktivierten Index 1 wird Index 2, der auch zunächst nach “Code 2” sortiert bevorzugt. Zu sehen am letzten Feld, welches den aktuellen Schlüssel (CURRENTKEY) anzeigt:

Aber keine Regel ohne Ausnahme. Selektieren Sie einen Schlüssel direkt interaktiv über die Oberfläche (Page, Form, Report), dann wird auch genau diese Sortierung genutzt. Im Folgenden habe ich wiederum den Key 1 gewählt und Sie sehen “Code 2” explizit als CURRENTKEY:

Oben habe ich erwähnt, dass das Verhalten der TableView-Eigenschaften analog zu SETCURRENTKEY funktioniert. Dementsprechend, wieder etwas magisch, können Sie auch hier explizit einen deaktivierten Schlüssel forcieren. Und zwar genau wie oben. Geben Sie einfach den Schlüssel bis zu einem Feld an, welches den auszuwählenden Key eindeutig macht. In unserem Fall wieder “Code 2,Code 1”:

Auch wenn es zunächst nicht so aussieht als ob diese Selektion möglich wäre, der Lookup gibt Ihnen hier keinen Aufschluss darüber, so können Sie diesen aber doch manuell erweitern oder überschreiben. Bei obiger Einstellung wird auch die Page/Form genau wie gewünscht mit Sortierung nach Schlüssel 1 (“Code 2") geöffnet, also eigentlich “Code 2,Code 1,Int”.

Beim nächsten Mal habe ich eventuell auch noch etwas “zauberhaftes” für Sie. Ich wünsche Ihnen ein entspanntes Wochenende und gehe davon aus, dass Sie es bei der Schlüsselauswahl für die Haustür einfacher haben  

Carsten Scholling

Microsoft Dynamics Germany
Microsoft Customer Service und Support (CSS) EMEA

Email: cschol@microsoft.com
Microsoft Connect: http://connect.microsoft.com
Online Support: http://www.microsoft.com/support
Sicherheitsupdates: http://www.microsoft.de/sicherheit

Microsoft Deutschland GmbH
Konrad-Zuse-Straße 1
D-85716 Unterschleißheim
http://www.microsoft.de