Dynamics NAV – Verwendung von Queries

Von | 29. Oktober 2016

Hallo liebe Leser,

mit Dynamics NAV 2013 wurde uns die Objektart Query (MSDN – Queries / MSDN – Working with Queries) vorgestellt und von Microsoft zur Verfügung gestellt. In der letzten Zeit sah ich mehrere alte Umsetzungen oder auch neue Anfragen zu Programmierungen, wo es sich förmlich anbot Queries als Objektart zu verwenden.

Daher möchte ich heute kurz darauf eingehen, wo und wann sich die Verwendung von Queries lohnen kann und habe dafür auch ein Beispiel vorbereitet. Meiner Meinung nach gibt es zwei signifikante Unterschiede zwischen RETEAP UNTIL NEXT Schleifen und Queries:

  1. Mit einem FINDSET oder FIND(‘-‘) werden immer alle Felder aus der entsprechenden Tabelle geholt. Bei der Query ruft man nur die benötigten Felder ab.
  2. Bei verschachtelten Schleifen (Beispiel Debitor -> Debitorenposten) wird zu jedem Debitor einzeln alle gefilterten Debitorenposten geholt. Eine Query holt diese Daten kombiniert, da das SQL Skript anders aufgebaut ist.

Wie groß der Unterschied zwischen einer Query und verschachtelten Schleifen oder auch Datasets sein kann, werde ich an folgender Anforderung zeigen:

“Erstelle einen Monatsbericht, der pro Monat und pro Mitarbeiter anzeigt, ob dieser mehr als 8 Stunden gearbeitet hat.”

Das Beispiel ist stark vereinfacht und bezieht sich jetzt auf folgende Tabellen: Ressource, Projektposten, (optional Projektbuchblattzeile). Wir befassen uns nur mit dem Ermitteln der erforderlichen Daten. Die Ausgabe und die Filterung lasse ich komplett außen vor.

Das Dataset könnte beispielsweise so aussehen:

  • Ressource –>Projektposten:
    1. Hierbei würden alle Projektposten einfach im Dataset übergeben und im RDL summiert. Alternativ dazu könnten wir die Daten auch im C/AL schon gruppieren (Buffertabelle)
    2. Die Laufzeit bei ca. 1 Millionen Projektposten beträgt bei mir ca. 42 Sekunden (nur die Verarbeitung im C/AL ohne Datasetübergabe oder Layout.

query_1_bericht1

  • Ressource –> Datum –> Projektposten:
    1. Pro Ressource bauen wir per Dataset eine Schleife über jeden Tag im Filter und laufen dann pro Tag durch die Projektposten der Ressource
    2. Die Laufzeit bei ca. 1 Millionen Projektposten beträgt bei mir auch hier ca. 42 Sekunden (nur die Verarbeitung im C/AL ohne Datasetübergabe oder Layout.

query_2_bericht2

query_3_bericht2_2

query_4_bericht2_3

Warum in diesem Fall nicht eine Query nutzen, die mir schon pro Ressource und pro Tag die summierte Menge ausgibt? Die Query muss dann so aussehen:

query_5_queryalsersatz

Wir benötigen die Ressourcennummer, das Buchungsdatum und das summierte Feld Menge. Sobald wir  “Method Type” = Totals auf dem Feld Menge einstellen, bekommen alle anderen Felder den Haken “Group by”. Die Ressourcen-Tabelle wird über die Nummer mit der Projektpostentabelle über den DataItemLink verknüpft. Ein Hinweis an dieser Stelle. Wer meint, dass die Ressourcentabelle als DataItem unnötig ist, der hat in diesem Fall Recht. Sobald ich aber beispielsweise den Namen aus der Tabelle nutzen möchte, macht der Aufbau so mehr Sinn und ist daher meiner Meinung nach zielführender. Das war’s, mehr muss man nicht machen. Führen wir die Query einfach mal aus:

query_6_queryalsersatz_2

Die Abfrage dauert keine 2 Sekunden, obwohl ich am 02.01.2016 1 Millionen Projektposten erstellt habe.

Diese Query integriere ich nun in einen Bericht. Leider weiß ich nicht wie viele Einträge die Query hat, daher habe ich mich entschieden, die Query in eine temporäre Buffer Tabelle zu schreiben und die Buffertabelle dann noch komplett zu durchlaufen (Gibt dazu auch ein HowDoI Video für eine Debitoren TOP 10 Liste: How Do I: Create a Report Using a Query in Microsoft Dynamics NAV 2013 R2)

query_7_queryimreport_1

query_8_queryimreport_2

query_9_queryimreport_3

Die Laufzeit beträgt dann sage und schreibe 2 Sekunden. Für mich ist das ein Unterschied wie Tag und Nacht. Ok, ich habe nun keine Möglichkeit alle Felder der Tabelle für die Filterung des Anwenders zu nutzen, aber das ist meistens auch nicht nötig. Die benötigten Felder kann man entsprechend als Filter in der Query und als Filter in der Requestpage (ausprogrammiert) hinterlegen und das sorgt für einen erheblichen Performanceboost.

Wer es selber ausprobieren möchte, kann die Objekte in einer Cronus DB ausführen. Ihr müsst Euch lediglich vorher genug Projektposten erstellen. FOB und TXT könnt ihr hier herunterladen: 161029_queryimreport.zip

Wer sich damit noch nicht befasst hat, sollte mal einen Blick darauf werfen. 🙂

3 Gedanken zu „Dynamics NAV – Verwendung von Queries

  1. Pingback: Dynamics NAV – Verwendung von Queries #2 – Generische Diagramme | Robert's Dynamics NAV Entwickler Blog

  2. Pingback: Dynamics NAV – Verwendung von Queries #2 – Generische Diagramme - Microsoft Dynamics NAV Community

  3. Pingback: Dynamics NAV – Verwendung von Queries #2 – Generische Diagramme - Robert's Dynamics NAV Entwickler Blog - Dynamics NAV Users - DUG

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert