Import einer FBK Version 2.6d

Hallo Zusammen,

ich muss aus unserem alten Navision 2.6d die Daten im besten Fall als CSV exportieren. Nun hatten wir als Nachfolger damals noch NAV 2009 R2. Ich dachte mir ich importiere die Daten in eine MSSQL in NAV 2009 R2 und exportiere sind dann. Bei mir scheitert es schon daran, dass einige Datumswerte beim Import nicht stimmen (s. Bild). Wir setzen nun seit ein paar Jahren kein Navision mehr ein und haben auch keinen Partner mehr und keine Develeoper Lizenz. Wie komme ich an mein Ziel?

Gruß,
Tom

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

In der nativen Navision Datenbank waren auch solche unrealistischen Datumswerte zulässig (Jahr 0000), was der SQL Server unterbindet. Hast du keine Möglichkeit die Datensicherung in einer nativen NAV DB zu importieren?

Doch schon aber wie bekomme ich denn die Daten exportiert ausser als FBK?

wie exportiert?
du hast eine fbk, so wie ich das verstehe
-> diese liest du bitte in eine native db ein (NICHT SQL!!!)

ich habe das schon ewig nicht mehr gemacht.
hier mal als kleine Starthilfe
https://www.dynamicsuser.net/t/open-a-database-fbk-in-navision-5-0-sp1/28847

aber die eigentliche Frage ist doch, wozu genau benötigst du das?

Ich habe jetzt das Backup wie du gesagt hast wieder importiert. Wie komme ich denn jetzt an die Daten heran? Ich benötige entweder ein CSV-File mit allen Daten und/oder eine Datei mit einem SQL-Dump. Das Ziel ist es ein Teil oder auch komplett die Daten in ein andere Datenbank (MySQL) zu übernehmen. Ob das Sinn macht hinterfrage ich jetzt nicht, so will es unser Investor.

Die Daten sind ja in Tabellen gespeichert. Einfach mal "alle Daten" exportieren geht mit NAV nicht. Du musst dir überlegen welche Tabellen du benötigst und diese dann exportieren. Das könnte z. B. auch mit der GDPdU Schnittstelle erfolgen, dann hast du ein standardisiertes Format, oder mit Dataports, oder (wenn's nur wenige Daten pro Tabelle sind) auch einfach mit Kopieren über Zwischenablage.

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
Die muss dann darin erst korrigieren, dann daraus noch mal eine Dasi als FBK erstellen und diese FBK dann in eine SQL-DB einlesen (von MS, nicht MySQL).

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.

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.

Und wie heißt dieses Tool? Ich habe keine Developer Lizenz.

Und wie heißt dieses Tool? Ich habe keine Developer Lizenz.

siehe den Beitrag von Kowa

Hallo,

meist sind aber nicht nur Datumsfelder faul, sondern mit 'ß' gibt es auch noch Porbleme.

Ich denke das einfachste ist eine native Datenbank und Dataports. Wenn die grundlegende Lizenz (die hoffentlich noch vorhanden ist) den Form und Report Designer enthielt, dann solltest du zumindest welche erstellen und laufen lassen können, wenn auch nicht als Objekt abspeichern.

Gruß Fiddi

Wenn ich den oben genannten FieldChecker ausführe, sagt er mir ich hätte keine Berechtigung zum Lesen der Tabelle "Database Field Updates". Wird das durch unsere Lizenz beschränkt?

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.

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.

Ich kann leider keine Fieldcheck.txt importieren und Dataports kann ich auch keine erstellen, NAV sagt ich hätte keine Berechtigungen und solle mich an den Systemadmin wenden. Was nun?

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.

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.

Also die Nummer 50010 wäre für Tabelle und Report frei. Codeunitssind laut Lizenz auch lizensiert. Fobs kann ich einlesen, wenn du mir eine bauen könntest, wäre das mega.

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.

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.

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

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.

Danke dir. Die Analyse hat tatsächlich Felder gefunden aber auf Grund meiner Lizenz kann ich jetzt nichts machen

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.

Gibt es keinen fertigen Report, um den Export vorzunehmen?

Das wurde doch bereits beantwortet -> Dataport, GDPDU-Export (sofern in 2.6 bereits vorhanden), Report....
Jedoch sollte man sich im Klaren sein, was für Daten exportiert werden sollen.
Wenn du wirklich alle Daten als CSV brauchst, dann hast du ne Menge Arbeit vor dir!

Das ist doch wohl eher das Problem, oder?

Ich habe keine Ahnung wie ich die Tabellen auslesen kann.

Es gibt genügend Beispiele, wie Daten per Dataport etc. exportiert werden können - diese sollten dir helfen:
http://partnersource.ru/cside.en/html/7b450158-be4e-43d9-8e42-8eaa32dc1e0b.htm
https://www.youtube.com/watch?v=Fo2hivTrmtQ

Wenn du das nicht möchtest und immer noch eine SQL-Migration durchführen willst, dann solltest du bei Partnern anfragen.

@aMilestone
Bitte Vollzitate vermeiden!

Gibt es keinen fertigen Report, um den Export vorzunehmen?

Nein, sonst nur den GDPdU-Export, wie von enh oben schon erwähnt.

Ich sehe, dass mein größtest Problem die Rechte sind. Ich kann keine Dataports und auch keine Reports erstellen. Bekommt man irgendwo eine Entwickler-Lizenz zum Test her?

Hallo,

wenn du also im Objektdesigner bei den Dataports nicht mal "New/Neu" drücken kannst, und sich der Dataportdesigner öffnet, dann hast du ein Problem. Ansonsten sollte das reichen um Daten zu exportieren.

Wenn das also nicht klappt, dann hilft wahrscheinlich nur der Weg über den Objektdesigner und ein "Run" auf die entsprechenden Tabellen und ein "Cut & Paste" der Datensätze aus ANV ins Excel.

Gruß Fiddi

Bekommt man irgendwo eine Entwickler-Lizenz zum Test her?

definitiv nicht

Die GDPdU Schnittstelle gibt es nicht für Nav 2.60 aber die ist problemlos downgradefähig, man verliert nur eine Form die im Nummernbereich überlagert, wenn man da nix dran tun will, und das war glaube ich eine Form aus Debitor/Kreditorposten-Ausgleich DE, insofern irrelevant wenn man nur Daten anschauen und exportieren will.

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

…bzw. konvertieren, wenn man die "Pappenheimer" vorher kennt .
Aus aktuellem Anlass zwei davon:
Bei einer laufenden Migration stolperte der SQL-Server über die Zeichen šž, die der Native Server fälschlicherweise als Kleinbuchstaben so in einem Codefeld ablegt (kamen hier direkt per ODBC-Import aus einem Textfeld in einem anderen SQL-Server ins System) anstatt, wie es sich gehört, als ŠŽ.
Diese kann man in der Request Form des Tools bei Code Feld Character Translation in den Controls für From Characters bzw. To Characters eingeben.