NAV-Objekte außerhalb von C/SIDE generieren

Können NAV-Objekte außerhalb von NAV erstellt werden? Sie können, und es gibt dafür "Fertiges".
Dieser Blog-Artikel berichtet von der Möglichkeit, mittels einer eigens entwickelten DLL für .NET neue NAV-Objekte außerhalb von C/SIDE zu erstellen. Ergebnis ist eine Textdatei, die nur noch im Object Designer importiert werden muss.

Für wen dies interessant klingt, findet hier mehr Informationen: http://www.uncommonsense.nl/cbreeze/

Hallo,

wenn man den Textimport benutzen kann, muss man da nicht unbedingt auf externe Komponenten zugreifen. Ein simpler Report tut es oft auch. Da ein NAV- Objekt eine relativ statische Angelegenheit ist.
Ich habe schon häufiger Tabellen aus anderen Tabellen erstellen müssen. dann habe ich mir einen Report gebaut z.B. basierend auf der Tabelle Field, der eine Textdatei erstellt. Im einfachsten Fall schreibt der im OnPreReport den Kopf der Tabelle, in den Dataitems die Felddefinitionen, und was sonst noch so gebraucht wird. Und im OnPostReport das Ende der Tabellendefinition. Was im Kopf und Fuß des Objekts stehen muss, kann man leicht durch eine selbst definiertes Objekt herausfinden. Das exportiert man als Text, kopiert die Passagen als Text- WRITES in den Report und ersetzt die Variablen Passagen durch ein paar STRSUBSTNOs.

Das ganze kann man beliebig komplizieren und aufwändiger gestalten, erfordert aber nicht unbedingt DotNet .

Gruß, Fiddi

Ich habe in dem ein oder anderen Projekt auch schon Tabellen automatisiert per Report bzw. Codeunit erstellen lassen.
Basis war eine Excel-Tabelle, in welcher der Consultant jede anzulegende Tabelle mit allen anzulegenden Feldern, Datentypen, Längen, TableRelations, ... definiert hatte.

Existierte die Tabelle noch nicht, so wurde sie als Text-Objekt in ein definiertes Verzeichnis geschrieben.
Existierte die Tabelle schon, so wurden die neuen Felder in der Tabelle Field eingetragen und das Objekt ggfls. in der Versionsliste markiert, falls CalcFormulas oder komplexe TableRelations nachgepflegt werden mussten.

Umgekehrt habe ich auch schon Reports geschrieben, die mir aus bestimmten Tabellen bestimmte Felder für ausgewählte Mandanten in einen SQL-View geschrieben haben und parallel dazu eine Text-Objekt schrieben, welches die dazu passende LinkedObject-Table repräsentierte.
SQL-View auf dem Server installiert, Table in NAV importiert, fertig war die mandantenübergreifende Sicht auf bestimmte Daten.

Trotzdem ist es natürlich interessant zu erfahren, dass es auch eine DotNet-basierte Lösung hierfür gibt.

Die Frage ist: Warum? Ich meine, wenn man schon eine 4G-Entwicklungsumgebung hat, warum sollte man dann wieder auf textbasierte, nicht-herstellerunterstützte Eigenprogrammierung zurückgreifen? Erschließt sich mir nicht ganz.

Wenn man das als Endkunde liest, macht mir eine solche Vorgehensweise ehrlich gesagt auch mehr Angst.
Das ist aber meine Meinung.

mfg,
winfy

Die Frage ist: Warum?

Es ist natürlich völlig sinnbefreit, ein Programm zu schreiben, welches einem eine Tabelle erstellt.
Wenn man jedoch im Zuge eines großen Projektes unzählige Tabellen zu erstellen hat, dessen detaillierte Definition bereits in einer anderen Datenquelle (z. B. Excel) existiert, dann sieht die Welt schon anders aus.
Im meinem o. g. Fall hätte ich hunderte Tabellen mit insgesamt tausenden Feldern anpassen bzw. erstellen müssen.
Durch die automatisierte Anlage bzw. Änderung sparte ich mir viele Tage "stupides Abtippen einer Excel-Tabelle" und konnte mich darauf konzentrieren, die wenigen neuen Felder in bereits vorhandenen Tabellen nachzuarbeiten (CalcFormulas, TableRelations, ...).

Die Frage ist: Warum? Ich meine, wenn man schon eine 4G-Entwicklungsumgebung hat, warum sollte man dann wieder auf textbasierte, nicht-herstellerunterstützte Eigenprogrammierung zurückgreifen? Erschließt sich mir nicht ganz.

Z.B. möchte für ein Upgrade alle Felder aus einer alten Version in einer Update-Tabelle sichern, die in einer neuen Version nicht mehr vorhanden sind. Mit einem geeigneten Bericht kann ich die komplette Kette der Objekte Sichern,Sicherungstabelle,Restore- Coderahmen automatisch erstellen. Das funktioniert automatisch wesentlich einfacher und sicherer, als wenn das ganze von Hand einzeln zusammen gebastelt wird.

Gruß, Fiddi

Die Frage ist: Warum?

Es ist natürlich völlig sinnbefreit, ein Programm zu schreiben, welches einem eine Tabelle erstellt.
Wenn man jedoch im Zuge eines großen Projektes unzählige Tabellen zu erstellen hat, dessen detaillierte Definition bereits in einer anderen Datenquelle (z. B. Excel) existiert, dann sieht die Welt schon anders aus.
Im meinem o. g. Fall hätte ich hunderte Tabellen mit insgesamt tausenden Feldern anpassen bzw. erstellen müssen.
Durch die automatisierte Anlage bzw. Änderung sparte ich mir viele Tage "stupides Abtippen einer Excel-Tabelle" und konnte mich darauf konzentrieren, die wenigen neuen Felder in bereits vorhandenen Tabellen nachzuarbeiten (CalcFormulas, TableRelations, ...).

Da frage ich wieder warum? Wenn jemand in der Lage ist, eine Tabellendefinition so im Detail anzugeben, dann ist er doch auch in der Lage die Tabelle selbst anzulegen. Warum sollte man die Definition einer Tabelle irgendwohin (in dem Fall Excel) auslagern, wo man keine (Test-)Kontrolle mehr per Compiler hat? Das kann doch nur vernünftig (fehlerfrei) funktionieren, wenn man sich auf einfache Felddefinitionen beschränkt und keine Logik in die Tabelle einbaut. Da fehlt mir im NAV-Umfeld einfach die Rolle des reinen Datenbank-/Relationsdesigners, so daß man diese Tätigkeit klar abtrennen könnte.

Die Frage ist: Warum? Ich meine, wenn man schon eine 4G-Entwicklungsumgebung hat, warum sollte man dann wieder auf textbasierte, nicht-herstellerunterstützte Eigenprogrammierung zurückgreifen? Erschließt sich mir nicht ganz.

Z.B. möchte für ein Upgrade alle Felder aus einer alten Version in einer Update-Tabelle sichern, die in einer neuen Version nicht mehr vorhanden sind. Mit einem geeigneten Bericht kann ich die komplette Kette der Objekte Sichern,Sicherungstabelle,Restore- Coderahmen automatisch erstellen. Das funktioniert automatisch wesentlich einfacher und sicherer, als wenn das ganze von Hand einzeln zusammen gebastelt wird.

Ich verstehe nicht ganz, was du da beim Updateprozess genau machen möchtest, aber die Daten sichert man doch über das Migrationstool, oder nicht?

Ich verstehe nicht ganz, was du da beim Updateprozess genau machen möchtest, aber die Daten sichert man doch über das Migrationstool, oder nicht?

und woher kommt das Migrationstool für die Kundentabellen?

Gruß, Fiddi

Das kann doch nur vernünftig (fehlerfrei) funktionieren, wenn man sich auf einfache Felddefinitionen beschränkt und keine Logik in die Tabelle einbaut. Da fehlt mir im NAV-Umfeld einfach die Rolle des reinen Datenbank-/Relationsdesigners, so daß man diese Tätigkeit klar abtrennen könnte.

In Großprojekten gibt es manchmal wirklich so getrennte Tätigkeitsfelder.
Und ja, in der Excel-Tabelle ist nur die Tabellen-/Feld-Definition beschrieben, nicht jedes einzelne Property und erst recht kein C/AL-Code.
Dennoch erspart es viele Tage Arbeit, wenn wenigstens die hundert Tabellen mit tausenden Feldern automatisiert angelegt werden konnten.

Ich verstehe nicht ganz, was du da beim Updateprozess genau machen möchtest, aber die Daten sichert man doch über das Migrationstool, oder nicht?

Wie Fiddi schon schrieb, kennt das Migrationstool nur die Standard-Tabellen und -Felder.
Sämtliche Individualfelder und -tabellen werden von diesem Tool nicht erfasst, so dass man es kundenindividuell erweitern muss.
Darüber hinaus müssen auch die Standardtabellen der neuen Version um die Individualfelder ergänzt werden, da sich diese beim Upgrade sonst nicht importieren lassen würden.

Es gibt also zahlreiche Fälle, wo es sinnvoll ist, Felder und/oder Tabellen automatisiert anzulegen.
Wie ich schon schrieb: Bei kleinen Anpassungen wäre es völlig sinnbefreit, ein Programm zu schreiben, welches die Anpassung vornimmt, aber bei größeren Projekten kann dies sehr nützlich sein, um entweder viel Zeit einzusparen oder wirklich alle Individualfelder und -tabellen zu erwischen.

Ich hatte das Thema sehr intensiv, als ich eine DB, deren Tabellen und Felder aus dem Individualbereich in den Nummernbereich einer Branchenlösung verschieben musste.

Gruß, Fiddi

Ich verstehe nicht ganz, was du da beim Updateprozess genau machen möchtest, aber die Daten sichert man doch über das Migrationstool, oder nicht?

und woher kommt das Migrationstool für die Kundentabellen?

Im Migrationstool kann ich doch die Tabellen und Felder angeben, die ich möchte. Also auch individuelle.

Im Migrationstool kann ich doch die Tabellen und Felder angeben, die ich möchte. Also auch individuelle.

meinst du das "RIM"- Toolkit mit Migration?

Wie machst du denn ein Update von einer NAV- Version auf eine andere? Dafür benutzt man das Upgradetoolkit, und das kann das nicht automatisch.

Gruß, Fiddi

Generell würde ich sagen, das ist eine Frage der Vorgehensweise. Wenn man dem Kunden möglichst jeden Wunsch erfüllen möchte, ungeachtet der Tatsache, daß eine Prozessanpassung langfristig vielleicht die bessere Alternative für ihn wäre, dann kommt man evtl. auf sehr viele Tabellen und dann können sicherlich in Excel definierte Tabellengrundgerüste interessant sein. Wobei ich mir dann immer noch die Frage stelle, wie sichergestellt wird, daß das Konzept des Excelbearbeiters in NAV Sinn macht und umsetzbar ist, und wer wie überprüft, ob die Prozesse, die mit der Exceldefinition umgesetzt werden sollen, nicht besser anders, vielleicht sogar anders in NAV, umgesetzt werden? Aber ich denke, das ist eine Frage der grundsätzlichen Vorgehensweise beim Update und würde hier zu weit führen, auch wenn ich die Diskussion hier ansich gerade interessant finde.

Wie machst du denn ein Update von einer NAV- Version auf eine andere? Dafür benutzt man das Upgradetoolkit, und das kann das nicht automatisch.

Für Datenkonvertierungen braucht man das Upgradetoolkit als Vorlage, das ist richtig.

wenn man den Textimport benutzen kann, muss man da nicht unbedingt auf externe Komponenten zugreifen. Ein simpler Report tut es oft auch. Da ein NAV- Objekt eine relativ statische Angelegenheit ist. [...]
Das ganze kann man beliebig komplizieren und aufwändiger gestalten, erfordert aber nicht unbedingt DotNet .

Jepp, ich wollte euch aber nicht vorenthalten, dass es sehr wohl so etwas - Fertiges - gibt.

Für Datenkonvertierungen braucht man das Upgradetoolkit als Vorlage, das ist richtig.

Wieso Vorlage?