Rezension "Programming Microsoft Dynamics NAV"

Dieses Buch von David Studebaker wendet sich an Leute mit einigem an Programmier- und kaufmännischem Hintergrundwissen, die vorhaben, einen Weg in ein NAV-System zu finden. Dies ist eine anspruchsvolle Aufgabe, weil NAV sich in der Arbeitsweise von anderen ERP–System unterscheidet, und der Autor hat die Aufgabe, den Weg in ein sehr komplexes System zu erleichtern, gut gelöst.

Eine einfache Beispielapplikation wird im Verlauf des Buches entwickelt. Alle Objekte (Tabellen , Forms , Reports ,Dataports, XMLPorts, Codeunits) werden anfangs mit ihren jeweiligen Basisfunktion und Eigenschaften erklärt, später dann detaillierter um die anspruchsvolleren Add-on-Funktionen zu implementieren. Ein paar der wichtigsten Codeunits, die aufrufbare Funktionen bereitstellen, die früher oder später jeder Entwickler suchen wird, werden besprochen, und indem der NAV Neuling die Verwendung dieser Funktionen nachvollzieht, wird er bald in der Lage sein, seine eigenen Funktionen und anschließend seine eigenen Erweiterungen zu programmieren.

Trotzdem sollte niemand glauben, dass er nach dem Lesen dieses Buches auf jedes NAV System losgelassen werden kann, kann um sich dort nach Lust und Laune auszutoben. Es benötigt viel Zeit, um die Langzeiteffekte von Codierungen abzuschätzen, und auch nach etlichen Jahren gibt es immer etwas Neues zu lernen, zu reparieren oder zu optimieren in einer Anwendung die sich rasant weiterentwickelt. Dies gilt umso mehr, wenn man vorhat, an vielen verschiedenen Datenbanken zu arbeiten, die erhebliche Individualänderungen haben können. Wer dieses Buch jedoch durcharbeitet, und sich außerdem die empfohlenen internen Dokumentationen und White Papers gewissenhaft anschaut, der hat dann schon eine ungefähre Vorstellung von dem, was ihn erwartet.

Natürlich gibt es eine ganze Reihe von fortgeschrittenen Themen, für die man in dem Buch nur eine kurze Einführung finden wird, wie z.B. die Interaktion mit externen Programmen, die Verwendung des NAV Application Servers oder den Datenaustausch mit Excel.

Ein sehr hilfreicher Vergleich zwischen dem "nativen" Server und dem SQL-Server ist ebenfalls enthalten. Sperrverhalten, Deadlocks und SQL-Performancethemen werden ausführlicher behandelt, aber nicht soweit das Codebeispiele von richtigen und falschen Programmierungen aufgeführt werden.

Zuletzt geändert von Kowa am 29. Dezember 2007 23:07, insgesamt 2-mal geändert.

Aus Platzgründen musste ich diesen Beitrag splitten.

Einige kleinere Problemstellen, die ich gefunden habe :

Seite 246: Obwohl temporäre Tabellen nur im Arbeitspeicher des Clients geladen werden, können Recordvariablen dieser Tabellen, die nicht temporär sind, in der Datenbank Datensätze löschen, ändern oder einfügen. Ein scheinbar harmloser Validate in einem Feldtrigger kann zu unbeabsichtigten Seiteneffekten führen. Dieses wird nicht erwähnt.

Seite 142/152: Die Formtrigger und Formcontroltrigger werden aufgeführt, und der Autor führt aus , dass es vermieden werden sollte , Code in diese Trigger zu schreiben. Obwohl dies in wesentlichen stimmt, wird der Neuling viel Code in Standardforms entdecken, und anfangs ziemliche Probleme die Interaktion zwischen Forms und Tabellen zu verstehen. Jede Kartenform benötigt eine Codezeile um den Filter auf dem Primärschlüssel zu entfernen, da sonst der Anwender nicht zum nächsten Datensatz wechseln kann, wenn die Kartenform aus der Übersicht aufgerufen wird. Dieses wird nicht erklärt. Anstatt Code unnötigerweise zu entfernen, sollte dieser lieber modifiziert werden, da auch der neue Objekttyp "Page", welcher mit NAV "6.0" eingeführt wird, größtenteils vergleichbare Trigger besitzen wird, es ist also ratsam, nur Funktionen in Codeunits aufzurufen, damit nicht zwei ähnliche Funktionen in zwei Objekten gewartet werden müssen.

Seite 237: Es wird nicht erwähnt, dass Endanwender ohne Application Designer Lizenz, die kleine Unternehmen meist nicht erwerben, Objekte im .txt-Format nicht importieren können. Es wird aufgeführt, dass nur erfahrene Entwickler die beiden Merge-Opitionen beim Import von .fob-Objekten verwenden sollten. Meiner Meinung nach sollte dieses unbedingt vermieden werden, es sei denn, es müssen Felder im Standardnummernbereich angelegt werden, die mit einer normalen Entwicklerlizenz nicht angelegt werden können, wenn das Objekt im .txt-Format vorliegt. Dann hat man keine Wahl, sollte aber den Code anschließend manuell nachmergen um sicherzustellen, dass kein Codebrei entstanden ist.

Seite 121: Die Beispiele für Datum und Bool für den AND Operator sind Wiederholungen für den Nicht-Gleich Operator.

Seite 301 : Einige Beispiele für die FORMAT Funktion wären hilfreich. Wenn man diese im Register sucht, findet man diese unter D (data format functions) nicht unter F.

Seite 345: Es wird aufgeführt, dass Codeunits 80/90 Buchungsblätter in Posten verarbeiten. Tatsächlich buchen diese Belege, indem sie die Daten in Buchungsblätter übertragen, die dann von Codeunits 12 (Fibu), 22 (Artikel) usw. verarbeitet werden.

Seite 439: Es wird behauptet, dass ein technisches Upgrade ein unumkehrbarer Vorgang ist. Es gibt hier aber eine Hintertür, falls dieses fehlschlägt, indem mit dem alten Client eine neue leere Datenbank aufgebaut wird, und die fbk-Datensicherung in diese Datenbank eingelesen wird. Ein volles Upgrade mit Objektänderungen dagegen, ist in der Tat ein unumkehrbarer Vorgang.

Die englische Version dieser Rezension ist hier zu finden.