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

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

Rate This
  • Comments 0

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!

clip_image002

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:

clip_image004

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:

 

Use the following guidelines when you use SETCURRENTKEY:

  • Use only the necessary key fields in a call of SETCURRENTKEY. If the table order is not important, then use only the fields that are used in the subsequent calls of SETRANGE and SETFILTER. If the definition of the key still includes the fields that are specified in the call of SETCURRENTKEY in the order given, then you can change the definition of the key without having to change any code.

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

 

  • When searching for a key, C/SIDE selects the first occurrence of the specified field(s). This means the following:
    If you specify only one field as a parameter when you call SETCURRENTKEY, then the key that is actually selected may consist of more than one field.
    If the field that you specify is the first component of several keys, then the key that is selected may not be the key that you expect.

“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 Smile

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:

image

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:

image

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:

image

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”:

image

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 Smile 

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

Leave a Comment
  • Please add 2 and 2 and type the answer here:
  • Post