HattrickHorst hat geschrieben:Die Frage ist: Warum?
HattrikHorst hat geschrieben: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.
Timo Lässer hat geschrieben:HattrickHorst hat geschrieben: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, ...).
fiddi hat geschrieben:HattrikHorst hat geschrieben: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?
In Großprojekten gibt es manchmal wirklich so getrennte Tätigkeitsfelder.HattrickHorst hat geschrieben: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.
Wie Fiddi schon schrieb, kennt das Migrationstool nur die Standard-Tabellen und -Felder.HattrickHorst hat geschrieben:Ich verstehe nicht ganz, was du da beim Updateprozess genau machen möchtest, aber die Daten sichert man doch über das Migrationstool, oder nicht?
fiddi hat geschrieben: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.
fiddi hat geschrieben: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.
Jepp, ich wollte euch aber nicht vorenthalten, dass es sehr wohl so etwas - Fertiges - gibt.fiddi hat geschrieben: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 .
Für Datenkonvertierungen braucht man das Upgradetoolkit als Vorlage, das ist richtig.
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast