Das neue Query-Objekt: kritische Würdigung

Hallo Gemeinde,

im folgenden habe ich ein paar Gedanken, die mir bei der aktuellen Arbeit mit NAV 2013 kamen, zusammengefasst und stelle diese hiermit zur Diskussion:

---
Eine wesentliche Neuerung in der Entwicklungsumgebung von Dynamics NAV stellt die Einführung des Query-Objekts dar. Dieses erlaubt die Verknüpfung von SQL Server-Tabellen und das Berechnen von Werten in einer Weise, wie man es unter SQL Server bisher von den Views („Sichten“) kannte. Das Query-Objekt ermöglicht also unter Dynamics NAV den Aufbau von SQL-Abfragen, ohne dass man sich der SQL-Syntax bzw. der SQL Server Management Konsole bedienen muss. Neben der einfacheren Erstellung ist vor allem die verbesserte Performance als Argument zu nennen, neue Anwendung mit dieser Technik zu entwickeln. Bestehende Anwendungen sollen lt. Microsoft mittels Query-Objekten performanter gestaltet werden. In bestimmten Anwendungsfällen könnten Query-Objekte den Einsatz von FlowFields obsolet machen.

SQL-Abfragen in NAV zu integrieren kann gesehen werden als eine logische Fortführung der Strategie, das Produkt von der nativen Datenbank abzukoppeln und konsequent auf den SQL Server zu setzen. SQL-Abfragen bieten hohen Komfort bei der Erstellung, lassen adhoc-Auswertungen zu und sind sehr performant. Sie stellen eine optimale Basis für viele Module dar, die gerne als Flaschenhals fungieren, wenn größere Datenmengen ins Spiel kommen. Als Alternative zu C/AL-Konstrukten für verknüpften Tabellen und FlowFields sind sie geradezu prädestiniert.

Die Entscheidung, Anwender und Entwickler nicht mit dem originären SQL-Code zu konfrontieren, erscheint vordergründig richtig. Insofern stellen die Query-Objekte mit ihrem Designer, dessen grundsätzlicher Aufbau von Reports und DataPorts her bereits bekannt ist, ein probates Mittel dar, die neuen Funktionen schnell bekannt zu machen. Eine Fokussierung auf die hauptsächlich benötigten Funktionen und Einstellungen erlaubt komfortable Einarbeitungszeiten, da man sich nicht mit allzu viel Overhead belasten muss. „Gefährliche“ SQL-Konstruktionen, wie Datenmanipulation oder UNION-Statements, sind auf diese Weise ausgeschlossen und erlauben den Erhalt einer gewissen qualitativen Stabilität.

Vor diesem Hintergrund ist es mit absolut unverständlich, warum man das Potential, das diese Technik repräsentiert, nicht einmal im Ansatz nutzt.

Query-Objekte können als Datengrundlage für Diagramme fungieren, oder mittels Web Services in OData-fähige Quellen übertragen werden. Außerdem kann man sie in der Entwicklungsumgebung aufrufen und die Ergebnisse in verschiedenen Formaten abspeichern. Diese Anwendungsvarianten stellen bestenfalls Spezialfälle dar, wenn nicht sogar exotische Vorgänge. Die interessanten Bereiche, nämlich Pages, Reports und XMLPorts, sind bisher ausgenommen von der Nutzung der neuen Techniken. In anderen Worten, ein Report, der eine Stunde lang läuft, um eine komplexe Datenaufbereitung zu vollziehen, wird trotz der neuen Technik immer noch eine Stunde laufen, weil man die Query-Objekte für diese Zwecke nicht heranziehen kann.

Microsoft spricht allerdings davon, diese Möglichkeiten in späteren Versionen zur Verfügung zu stellen.

Eine tatsächliche Verbesserung der Performance lässt sich interessanterweise mit einer Funktion erreichen, die es bereits seit längerem gibt: die LinkedObject-Eigenschaft. Hiermit kann ein beliebiges SQL-View als Tabelle eingebunden werden und steht damit sofort für Pages, Reports und XMLPorts zur Verfügung. Außerdem kann man auf diese Art und Weise alle Funktionen und Spielarten von SQL verwenden, nicht nur diejenigen, die Microsoft für „angemessen“ hält. Der Nachteil dabei ist, dass man sich mit dem SQL Server Management Studio und der originären SQL-Syntax auseinandersetzen muss. Da aber Microsoft vermutlich sowieso darauf abzielt, NAV gegenüber dem SQL Server zu öffnen, steht diese Auseinandersetzung sowieso früher oder später an. Dummerweise ist es nicht möglich, sich mit einem Query-Objekt eine Vorlage zu basteln und dessen SQL-Anweisungen im Klartext auszugeben, um diese dann im SQL-Server als Grundlage für einen View zu verwenden. Das wäre noch einigermaßen komfortabel und ist schon seit Jahren gang und gäbe, siehe den Makro-Recorder für VBA in Microsoft-Office-Produkten.
---


Mit besten Grüßen,

Stefan

Zuletzt geändert von ResMan am 5. April 2013 12:36, insgesamt 1-mal geändert.

Hallo Stefan,

man kann doch die Query-Objekte in Reports und Pages benutzen. Die Ergebnisse werden einfach in temporäre Recordvariablen geschrieben und können dann wie gewohnt genutzt werden oder verstehe ich das falsch? Auch kann man die SQL-Anweisung über den SQL Profiler abgreifen.

Mit den SQL-Views und LinkedObjects hatte ich schon diverse Performanceprobleme, so dass das nicht wirklich hilft. Zudem ist das Anlegen von neuen Mandanten und das Einlesen von FBK-Datensicherungen mit LinkedObjects lästig.

man kann doch die Query-Objekte in Reports und Pages benutzen. Die Ergebnisse werden einfach in temporäre Recordvariablen geschrieben und können dann wie gewohnt genutzt werden oder verstehe ich das falsch?

Das ist ein Workaround, den man auch mit DotNet-Variablen und ADO.NET hätte machen können.
Interessant wäre m.E. die echte Integration, d.h. Queries als Basis für die genannten Objekte, so dass sich einiges an Codierung erübrigt.

Mit den SQL-Views und LinkedObjects hatte ich schon diverse Performanceprobleme, so dass das nicht wirklich hilft.

Klar, wenn schon auf SQL-Seite die Performance nicht passt, bringt diese Methode auch nix mehr.

Zudem ist das Anlegen von neuen Mandanten und das Einlesen von FBK-Datensicherungen mit LinkedObjects lästig.

Hier gilt es, die Nachteile abzuwägen gegen erhöhte Performance.

Beste Grüße,

Stefan

Als jemand der schon lange SQL Views in NAV benutzt, stellt sich mir die Frage: was ist dein Punkt?

Dass Queries nicht nativ in Reports verwendet werden können? Geschenkt. Wird wohl in Zukunft implementiert.

Dass man mit Queries nicht alle Statements der SQL-Syntax verwenden kann? Warum auch, wer das will, sollte T-SQL lernen. Das mangelnde Wissen und Verständnis über den SQL-Server und die Funktionsweise von verschiedenen Abfragemethoden ist eh ein Performancekiller. Natürlich kann man jetzt sagen: mit der alten nativen DB von Navision war alles besser. Da brauchte man quasi überhaupt kein Verständnis der DB-Engine. Ich bin jedenfalls zufrieden, dass es Views und LinkedObjects gibt und habe schon so manchen Report damit deutlich beschleunigt bzw. manchmal auch überhaupt erst ermöglicht. Ich habe allerdings schon vor meiner NAV-Zeit intensiv mit mySQL gearbeitet und kannte mich insofern in der T-SQL-Welt schon gut aus.

Also nochmal: was ist der Punkt? Dass MS eine neue Funktion zur Verfügung stellt, die sicherlich noch erweitert wird, aber wahrscheinlich nie alle Möglichkeiten von T-SQL zur Verfügung stellt? Naja, erscheint mir irgendwie logisch. Ich würde mir wenn dann wünschen, dass ich direkt das T-SQL in eine Query schreiben kann, damit dann wirklich alles vereint ist. Eine View als LinkedObject müsste man ja dann wieder über eine Page oder eine Query erstellen, um diese als WebService zu veröffentlichen, ist aber auch nicht dramatisch.

Was dann tatsächlich bei LinkedObjects nervt, sind evtl. Datensicherungen und Mandantenänderungen. Hier sollte MS meiner Meinung nach nachbessern und diese Objekte einfach ignorieren.

Microsoft spricht allerdings davon, diese Möglichkeiten in späteren Versionen zur Verfügung zu stellen.

Langfristig sollen praktisch alle Stellen, wo heute noch SETRANGE oder SETFILTER steht, durch Querys ersetzt werden. Das wurde von den Core-Entwicklern zumindest auf den letzten NAV TechDays so angekündigt. Das geht natürlich nicht von heute auf morgen.

Langfristig sollen praktisch alle Stellen, wo heute noch SETRANGE oder SETFILTER steht, durch Querys ersetzt werden.

womit wir dann wohl bei AX wären, wenn ich mich recht erinnere war das da schon von Anfang an so.

Gruß, fiddi

was ist dein Punkt?

Was mich am meisten stört, ist die mehr als zögerliche Umsetzung dieser an sich guten Idee. Warum hat man die Query-Objekte nicht den Tabellen gleichgesetzt? Warum diese Beschränkung auf exotische Anwendungsfälle? Man muss die Objekte ja nicht benutzen, wenn man nicht will (oder kann).

Soviel "Rücksicht" auf die Befindlichkeiten der Entwicklergemeinde nimmt M$ normalerweise eigentlich nicht, soweit ich mich erinnere.

Wenn man jedoch will (oder kann), lässt sich das Potential von SQL nicht ausschöpfen. Das finde ich ... enttäuschend.
Ich habe vor meiner NAV-Zeit jahrelang SQL Server-Anwendungen erstellt. Daher fand ich die Query-Objekte anfangs sehr vielversprechend.

Beste Grüße,

Stefan

Aber es ist doch nur eine Frage der Zeit. Ich kann ja auch die Frage stellen: warum hat Microsoft nicht direkt NAV 2013 veröffentlicht, sondern ist den Weg über NAV 2009 gegangen? Ich habe keine Ahnung wo die Reise hingeht, aber falls wir mal statt in C/AL direkt in C# programmieren und damit nicht mehr den doch starken Beschränkungen des C/AL-Editors ausgesetzt sind, könnte man ja auch Fragen: warum hat MS das nicht direkt so gemacht? Da du offensichtlich selbst Entwickler bist, weißt du die Antwort bereits, oder?

Ist nicht böse gemeint, aber in diesem Fall hat doch MS sogar schon angedeutet, dass es für zukünftige Versionen vorgesehen ist. Das ist natürlich keine Garantie, aber es ist (wie du ja selbst feststelltest) eigentlich eine so logische Konsequenz, dass ich mir nicht vorstellen kann, dass MS das nicht auch tatsächlich tut. Und somit ist es doch nur eine Frage der Zeit, vielleicht mit 2013 SP1? Oder mit NAV 2014?

2014 wird angeblich keine großartigen veränderungen für uns entwickler beinhalten, sondern lediglich oberflächliche änderungen.
erst 2015 sollen veränderungen an objekten und am core durchgeführt werden - so mein kenntnisstand

Soviel "Rücksicht" auf die Befindlichkeiten der Entwicklergemeinde nimmt M$ normalerweise eigentlich nicht, soweit ich mich erinnere.

Für die technischen Umwälzungen, die seit NAV 2009 eingesetzt haben, zitiere ich mal aus einem Vortrag von Michael Nielsen ( Director of Development for Dynamics NAV) "…and most important, don't break anything.", u.a. deshalb kommen die neuen Technologien per "Salamitaktik".

Na, ich bin im Zweifel, ob sich da so schnell was ändert. Vor allem, nachdem man den ersten Schritt hier schon so zögerlich getan hat, Salamitaktik hin oder her.
Aber ich lasse mich gerne vom Gegenteil überzeugen. Also, an alle M$-Mitarbeiter, die das lesen: bitte macht weiter damit, die Richtung ist gut!

(Gerne auch als Hotfix für 2013 )

Stefan

don't break anything."

... und dann kam der neue Report Designer!!

... und dann kam der neue Report Designer!!

Die Frage ist, worauf sich die Salamitaktik bezieht. Auf die Einführung neuer Technologien oder deren Funktionsfähigkeit

Gruß, Fiddi