Backup / Restore Nav 4.03 in NAV 5.01

Hallo,

ich hoffe es kann mir jemand von euch bei meinem Problem helfen, da ich ziemlich neu bin in NAV.

Wir haben 4.03 im Einsatz und möchten nun auf 5.01 wechseln. Hardwaremässig ist alles vorbereitet. Ich habe einen Export von 4.03 gemacht und beim Import kommt immer eine Fehlermeldung: Das Datum 01.03.0207 ist fehlerhaft.

In NAV 4.03 waren solche Zubuchungen scheinbar kein Problem und wurden auch nicht durch eine gute Prüfung abgefangen. Da wir nun solchen Daten in NAV haben, ist ein Import scheinbar nicht möglich.

Habt ihr eine Lösung dafür?

lg
Markus

Hallo Markus,

zuerst darf ich dich ganz herzlich in unserer Community willkommen heissen.

Wir haben 4.03 im Einsatz und möchten nun auf 5.01 wechseln.

Nur zur Info:
Es gibt keine Version 4.03 und auch keine Version 5.01.
Jedoch gibt es NAV 4.00 SP3 sowie NAV 5.00 SP1.
Leider sprechen viele MBSP der Einfachheit halber von den von dir zitierten Versionen.

Das Datum 01.03.0207 ist fehlerhaft.

Ich gehe mal davon aus, dass ihr vom Navision Database Server auf Microsoft SQL-Server umstellt, denn:
Der Navision Database Server kennt alle Dati vom 01.01.0001 bis 31.12.9999.
Der SQL-Server kennt jedoch nur die Dati seit dem 01.01.175x (ich weiß es leider nicht ganz genau).
Lösung: Ihr müsst diese Tippfehler vor der Konvertierung korrigieren.
Hierzu gibt es ein "Migration-Toolkit", welches euer Partner haben sollte.

Dieses Tool sucht sämtliche "fehlerhafte" Dati und bietet die Möglichkeit der automatisierten Korrektur.
Frage einfach mal euren MBSP nach einer Testkonvertierung von Native auf SQL.

Der SQL-Server kennt jedoch nur die Dati seit dem 01.01.175x (ich weiß es leider nicht ganz genau).

01.01.1753 ( aus historischen Kalenderumstellungsgründen , nicht aus technischen).

1753 is the earliest year accepted by Sql Server. There are two calendar types in the western world. The Julian and the Gregorian calendars. These calendars did not match up by x number of days, depending on the year you are comparing. Eventually, countries started switching from the Julian calendar to the Gregorian calendar, which meant during the switch, they would have to skip forward anywhere from 10-13 days. Italy, Poland, Portugal, and Spain made this switch way back in 1582 and advanced 10 days forward. Great Britian made the switch in 1782, advancing 12 days forward. Albania switched in 1912, advancing 13 days forward. In the United States, depending on which part of the country you were in, you changed calendars anywhere from 1582 to 1867. Since most parts of the world changed calendars prior to 1753, this was chosen as the cut off date in Sql Server/Sybase. In order to calculate an actual date any earlier than that, you would have to go through this conversion process that would require you to know not only the country in which you are converting the date for, but also what year they did their conversion to the Gregorian calendar.

Danke für die freundliche Aufnahme in euer Forum und die Hilfe.

Unser Partner hat das Tool, hat unseren Export dort drüber laufen lassen und es hat wieder nicht funktioniert.

Es gibt Probleme mit den Zeichen. Wir haben einen Artikel in unserer NAV 4.00 SP3 DB mit einem â
Daraus ist beim Import ein ae (Sonderzeichen kann ich hier nicht darstellen) und das verursacht beim Import einen Fehler. Weiss jemand warum es dazu überhaupt kommen kann?

Danke
Markus

Liegt eventuell an der Spracheinstellung des SQL-Servers

Hallo,

das sagt unser NAV Partner auch. Es kann aber nicht sein. Wir haben den SQL Server standard mit Latin1_General_CI_AS aufgesetzt und die DB selbst beim Einrichten mit Windows Sortierung Deutsch ... aufgesetzt. Beim Check am SQL Server direkt steht auch bei den DB Properties Latin1_General_CI_AS. Das ist doch die Codepage 1252 die dann dahinter liegt.

Diese Codepage kann doch auch französische Sonderzeichen. Ausserdem haben wir schon probiert eine TEST DB mit ca. 100 MB mit allen Sonderzeichen anzulegen. Das hat prima geklappt. Daher schliesse ich die Codepage aus.

lg
Markus Baldauf