Timo Lässer hat geschrieben:Um eine native NAV-Datenbank auf SQL umzustellen, gibt es ein SQL-Migrations-Tool, welches alle Daten in allen Tabellen dahingehend prüft, ob sie SQL-kompatibel sind.
Wenn ich mich richtig erinnere, kann dieses Tool die Daten (z. B. Datum 01.01.0000) konvertieren/korrigieren, so dass es anschließend valide Daten enthält.
AnschlieĂźend kannst du dir wieder eine FBK ziehen und diese mit NAV2009 in eine SQL-Datenbank einlesen.
aMilestone hat geschrieben:Und wie heiĂźt dieses Tool? Ich habe keine Developer Lizenz.
aMilestone hat geschrieben: Wird das durch unsere Lizenz beschränkt?
Kowa hat geschrieben:aMilestone hat geschrieben: Wird das durch unsere Lizenz beschränkt?
Ja, das Tool verwendet Tabelle und Report 79002, die nur selten in einer Kundenlizenz vorhanden sind. Das kann in der FieldCheck.txt geändert werden (auf Objektnummern, die in der Lizenz freigegeben sind), und dann diese Textdatei importieren, nicht die Fob.
Kowa hat geschrieben:Welche Objektnummern (eine Tabelle und ein Report) sind denn ĂĽberhaupt frei? Notfalls kann ich eine angepasste Fob erstellen, die genau diese verwendet.
Den Export könnte man auch über Codeunits vornehmen (da muss man aber schon reichlich programmieren, das könnte aber ggf. ein Freiberufler sicherlich hinbekommen), sind die denn lizenziert?
Der Export würde auch mit SQL-Tools aus der SQL-DB möglich sein, sobald diese erstellt ist, wenn sonst gar nichts geht.
Kowa hat geschrieben:Im Anhang ist eine Fob für Tabellen- bzw. Report ID 50010. Importieren und die Analyse ausführen solltest du damit können, die Ursprungsobjekte mit der ID 79002 vorher löschen. Falls das mit deiner Lizenz nicht geht, müssen die Objektnamen leicht abgeändert werden, dann kann ich noch mal eine neue Fob erstellen.
Falls allerdings die Analyse problematische Feldinhalte in Tabellen ermittelt, die mit deiner Lizenz nicht geändert werden dürfen, wird es ohne Entwicklerlizenz nicht weitergehen.
Kowa hat geschrieben:Den Dateiexport könnte man auch über einen Report vornehmen, Links siehe hier.
Da geht es zwar um feste Feldlängen, aber für CSV lässt man das PADSTR weg und vewendet das Semikolon als Trennzeichen. Wichtig dabei ist aber, dass sich in den Feldern selber keine Semikolons befinden dürfen. Die muss man vorher über CONVERTSTR durch ein Komma austauschen, das muss also bei jedem Feldinhalt sicherheitshalber angewandt werden.
Gibt es keinen fertigen Report, um den Export vorzunehmen?
Ich habe keine Ahnung wie ich die Tabellen auslesen kann.
Nein, sonst nur den GDPdU-Export, wie von enh oben schon erwähnt.aMilestone hat geschrieben:Gibt es keinen fertigen Report, um den Export vorzunehmen?
aMilestone hat geschrieben:Bekommt man irgendwo eine Entwickler-Lizenz zum Test her?
Kowa hat geschrieben:Wenn man die DB in der nativen DB hat, kann man mit diesem Tool die Feldinhalte ermitteln, die der SQL-Server nicht verarbeiten kann.
Field Check v3
Mitglieder in diesem Forum: Unbekannter Robot und 1 Gast