[Gelöst] -[CC] SQLMigration - Code Field Infos Incorrect Dat

Hi,

ich versuche gerade das SQL Migration Kit anzuwenden (Chapter 5 - Migrating Dynamics Nav with SQL Server)
und habe dazu ein paar Fragen.

Ausgangsdatenbank ist eine 3.70er Datenbank, konvertiert nach 2009 und diese soll im Anschluss direkt nach 2009 SQL. Da soll ich gerade herausfinden wie Zeitintensiv die Migration ist und welche Probleme dabei auftauchen können/werden.

Punkt 5.2 Checking the Old Database -> 5.2.8 Run Codeunit 104015 Field Check

Nach dem ausführen der Codeunit 104015 öffnet sich ein Form mit einer Auflistung von Datensätzen dessen Feldinhalte nicht für SQL Anwendbar sind.

Hier kann ich diese Datensätze korrigieren, das klappt auch für die meisten Datensätze, nun habe ich vereinzelt Datensätze bei denen es mir nicht möglich ist "New Value" zu überschreiben (Fehler: There is no Field within the Filter, FIlters: TableNo: 50xxx, FieldName: Namexxx), betrifft also eine Tabelle die von uns erstellt wurde.

Nun steht im Manual:

You can modify these suggestions if you want. When you close the window, a
message will appear asking you whether or not you want to implement the changes.
If you click Yes, the program will implement the changes. The program will read and
modify a small number of records in the database during this step

Was passiert an dieser Stelle? Werden die Änderungen schon in irgendeiner Art und Weise auf die Datenbank angewendet? Ich konnte ja keinen neuen Wert für den o.g. Korrupten Datensatz eintragen. Habe dann den neuen Wert für diesen korrupten Datensatz dann direkt in der Tabelle 104010 geändert, hier wurde nichts angemeckert.

Nun Frage ich mich ob ich diese Tabelle (104010) dazu nutzen kann die korrupten Datensätze zu korrigieren, denn mir ist jetzt schon 2 mal passiert , das nachdem Ausführen der Codeunit 104015 ich das Ergebnis Form geschlossen habe, und der ein oder andere Datensatz angemeckert wurde, und ich jetzt nicht weiß ob das schon die letzte Möglichkeit war ein Datensatz zu ändern. (Die Codeunit 104015 braucht so ca. 7 Std), also nochmal ausführen und dann erneut Ändern braucht Zeit. Deswegen der Sicherheit lieber die Frage ob ich auch nach dem Schritt noch die Daten ändern kann.


Nächster Punkt: Mit der Codeunit 104015 werden auch die Code Felder Analysiert, das Ergebnis wird in Form 104013 angezeigt (nicht editierbar) , hier wird so einiges gelistet .... Die Übernahme der CodeFelder mit gemischter Natur (Zeichen / Ziffern) führt zu Sortierproblemen in SQL, um die Migration möglichst "kurz" zu halten wollen wir nur die wichtigen Felder behandeln, und alles andere später wenn die Migration erfolgt ist (Artikel Nummern, Debitoren Codes usw..)

Wenn ich das Manual richtig verstehe, beschränkt sich das auf folgende 3 Einträge:
Table Name |Table ID |Field Name |Field No.
G/L Account |15 |No. |1
Acc. Schedule Line |85 |Row No. |3
VAT Statement Line |256 |Row No. |4

Einen Numbering Conflict wird hier für die Tabelle Acc. Schedule Line (z.B. 8050, UMIN,..) und G/L Account angezeigt (z.B.: 20, HANDEL16,...)

Diese Codes sollten also am besten einheitlich (nur Text oder nur Integer) sein damit es nach der Migration keine unerwünschten Ergebnisse gibt?

Ist die Annahme auch korrekt das alle anderen Felder erstmal ignoriert werden können?

Vielen Dank
Peter

Zuletzt geändert von elTorito am 30. Dezember 2011 22:09, insgesamt 1-mal geändert.

Ausgangsdatenbank ist eine 3.70er Datenbank, konvertiert nach 2009 und diese soll im Anschluss direkt nach 2009 SQL.

Migration nach SQL habe ich noch nie gemacht, aber war es nicht so, dass man von 3.7 auf 2009 erst den Zwischenschritt auf 4.03 machen sollte?

Volker

Hallo,

Probiere mal alternativ das Tool hier (MIBUSO) oder hier (MIBUSO)aus.

Die sind etwas schneller (zumindest das erste) Dazu solltest du deine Native- DB aber mit NAV 2009 Technik laufen lassen.

Migration nach SQL habe ich noch nie gemacht, aber war es nicht so, dass man von 3.7 auf 2009 erst den Zwischenschritt auf 4.03 machen sollte?

Also man muss hier zwei Dinge unterscheiden: Die Migration nach SQL was elTorito zunächst vorhat , und der Update der Applikation was du meinst. Die Migration nach SQL kannst du theoretisch direkt machen, wenn NAV2009 die FBK lesen kann, für Die Anwendung kann man nur in den Schritten machen, für die es ein Upgradetoolkit gibt.

Gruß, Fiddi

Hallo,

Probiere mal alternativ das Tool hier (MIBUSO) oder hier (MIBUSO)aus.

Die sind etwas schneller (zumindest das erste) Dazu solltest du deine Native- DB aber mit NAV 2009 Technik laufen lassen.

Hi Fiddi,

danke für die Links, das erste Tool laeuft gerade,...

If the 'logging only' flag is turned on the value will be saved in the "Database Field Updates" table. Where is can be copied, modified and later applied by pressing the "Run updates" button.

Wenn ich richtig verstehe (mein Englisch ist nicht so gut ...) dann heist das, wenn Log Flag angekreuzt, werden die betroffenen Daten weggespeichert, und können dann in der Table Database Field Updates behandelt werden? Und diese Änderungen werden dann mit "Run Updates" auf die entsperchenden Live Datensätze angewendet?

@vsnase

aber war es nicht so, dass man von 3.7 auf 2009 erst den Zwischenschritt auf 4.03 machen sollte?

das weiß ich nicht ob man das machen sollte, fakt ist wir haben 3.70 und die Update Routinen unseres NSC Updaten die Datenbank auf 2009, daher wird das vermutlich ok sein .

@fiddi:

Dazu solltest du deine Native- DB aber mit NAV 2009 Technik laufen lassen.

ehm. ja... puh... das heißt? :) Habe die 2009er DB mit dem Client geöffnet und dort läuft gerade der Report von Mibuso drüber, hoffe das war so gemeint :)

Vielen Dank
gruß
Peter

Randnotiz:
Wenn Du DACH Addons hast, wird die erstellte Fieldcheck Codeunit sich eh nicht kompilieren lassen, da es jemand der die DACH Addons programmiert geschafft hat, Systemnamen als Feldname zu definieren (Fieldname als Feldname).

Hi,

also ich komm mit den Mibuso Tool nicht klar, habe den report ausgeführt mit Log To DB Updates Table Only, darauf hin habe ich nun in der Tabelle 79002 - Database Field Updates, ca. 221.000 Datensätze, mit den Microsoft Migrations Kit hatte ich nur 382 Datensätze in der Tabelle 104010 - Incorrect Data Value.

Wenn ich nun wieder den Mibuso Report 79002 Field Check For SQL Ausführe und dort "Run Updates" wähle , scheppert es direkt mit der Meldung : "Profil ist bereits mit einem Standard Rollencenter vorhanden" (Betrifft Datensätze in Tabelle 2000000072) ...

Wenn ich ein *fbk exportiere und in SQL versuche zu importieren, bricht mir der Import bei irgendeinen Debitor ab der wohl ein Leerzeichen im DebitorenCode Feld hat...

Stehe gerade etwas auf den Schlauch und weiß nicht wie ich das alles angehen soll. Wäre hier sinnvoll bei unserem NSC nach einer Schulung zu fragen? Da würde man wahrscheinlich anhand von Cronus den Idealfall gezeigt bekommen , daher weiß ich nicht wie hilfreich das sein kann.

An vielen Datensätze welche der Mibuso Report mir generiert hat erkenne ich auch keine Fehlerhaften Daten , Zeichen und Länge eingehalten... Die Datensätze welches das Microsoft Toolkit in die Tabelle 104010 generiert hat, hatte ich alle korrigiert, und trotzdem schlägt der fbk Import fehl (wahrscheinlich weil das MS Tool z.B. nicht auf Leerzeichen in Codefelder prüft?)

Mal konkret gefragt: Gibt es, oder ist vielleicht möglich mit eins der Toolkit/Report fehlerhafte Datensätze zu finden, diese zu korrigeiren, erneut prüfen , solange bis keiner mehr übrig ist?

@JanGD: in der versionsliste finde ich zwar DACH*** Versions Nummern, aber da die FieldCHK kompiliert werden konnte denke ich mal haben wir da nichts spezifisches?

Was meint Ihr, kann man das selber in den Griff bekommen, oder wie könnte mir das NSC dabei behilflich sein? Bzw. was müssten die mir beibringen damit ich das selber hinbekomme.

Vielen Dank.
Peter

Hallo,

hast Du einen deutschsprachigen Objektstand? (TabellenNAME Debitor statt Customer)
Wenn ja, dürfte der Fehler nicht auftreten. Bei dem Objektstand ab Version 4 oder so ist alles auf englisch mit deutscher Caption. Dann heißt das fehlerhafte Feld nicht mehr Feldname (kein Systemausdruck) sondern Fieldname (und das ist ein Systemausdruck).

Bei meinen Migrationen habe ich bis jetzt immer das MS Tool genommen. 7 Stunden Laufzeit sind nicht kritisch, sofern kein 24/7 Betrieb vorhanden ist.
Restore einer FBK in SQL bricht immer am ersten "fehlerhaften" Feldinhalt ab. Daher braucht man ja den fieldcheck.

Ich würde die Fieldcheck-Form auch erstmal benutzen, um zu idenfitizieren, ob es ein generelles/systematisches Problem ist, oder nur vereinzelt. Es gibt sicherlich auch Fälle, wo ihr vor der SQL Umstellung die Daten schon beheben könnt. Einige Stellen gehen natürlich nicht (weil auf Postenebene z.B.).

Viele Grüße
Jan

Hallo Jan,

hast Du einen deutschsprachigen Objektstand? (TabellenNAME Debitor statt Customer)

ja, den haben wir.

Dann heißt das fehlerhafte Feld nicht mehr Feldname (kein Systemausdruck) sondern Fieldname (und das ist ein Systemausdruck).

Unser NSC empfahl mir vor der Migration die Sprache auf Englisch zu ändern, sonst könne es zu fehlern kommen. Hoffe das hängt da nicht irgendwie mit zusammen.

Bei meinen Migrationen habe ich bis jetzt immer das MS Tool genommen. 7 Stunden Laufzeit sind nicht kritisch, sofern kein 24/7 Betrieb vorhanden ist.
Restore einer FBK in SQL bricht immer am ersten "fehlerhaften" Feldinhalt ab. Daher braucht man ja den fieldcheck.

Ich würde auch gerne bei dem MS Tool bleiben, da wir das Kit über unseren NSC bekommen haben, und ich möchte natürlich so wenig Schritte wie möglich, der Report voN Mibuso ist sehr Umfangreich schon was die Einstellungen angeht, wenn weniger auch reicht, wäre ich zufrieden .

Ich habe jetzt nochmal eine c:\fieldchk.txt generiuert und diese impoertiert, wurde ohne Fehler kompiliert, nun läuft die Routine...

Ich würde die Fieldcheck-Form auch erstmal benutzen, um zu idenfitizieren, ob es ein generelles/systematisches Problem ist, oder nur vereinzelt. Es gibt sicherlich auch Fälle, wo ihr vor der SQL Umstellung die Daten schon beheben könnt. Einige Stellen gehen natürlich nicht (weil auf Postenebene z.B.).

Du meinst die Datensätze der Tabelle 104010 ? Werde ich machen. Soweit ich beim letzten Durchlauf gesehen hatte waren nur ca 8 Einträge mit falschen Auftrags Datum , und sonst nur Überlange Texteinträge in diversen Textfeldern (Feldlänge = 30, Text aber > 30 zeichen...)

Es gibt sicherlich auch Fälle, wo ihr vor der SQL Umstellung die Daten schon beheben könnt.

Das wäre natürlich sehr schön :) Das will ich auch versuchen, aber dafür muss ich ja erstmal die Fehlerhaften Datensätze finden, und wenn das eine Toolkit mir xx ankreidet, und das andere xxxx, und ich dort bei vielen datensätzen keine Invalidität erkenne macht es die Sache nicht gerade einfach.

Vielen dank nochmal und schönes Wochenende

Peter

An vielen Datensätze welche der Mibuso Report mir generiert hat erkenne ich auch keine Fehlerhaften Daten , Zeichen und Länge eingehalten... Die Datensätze welches das Microsoft Toolkit in die Tabelle 104010 generiert hat, hatte ich alle korrigiert, und trotzdem schlägt der fbk Import fehl (wahrscheinlich weil das MS Tool z.B. nicht auf Leerzeichen in Codefelder prüft?)

Die Erfahrung durfte ich leider auch schon machen. NAV Native hat so ein paar Eigenheiten und 2009 im speziellen. In Native dürfen textfelder ein Zeichen länger sein als erlaubt ( dazu gehören auch Leerrzeichen), 2009 hat außerdem die Angewohnheit Sonderzeichen nicht mehr anzuzeigen (man merkt das nur daran, dass nach dem Drücken von ENTF scheinbar nichts passiert) Das alles prüft der Report, und korrigiert es.

Gruß, Fiddi

Hallo,

jetzt muss ich doch noch meinen Senf zu dieser never-ending-story dazugeben.

Was mich etwas irritert, ist diese Aussage:

Hallo Jan,

hast Du einen deutschsprachigen Objektstand? (TabellenNAME Debitor statt Customer)

ja, den haben wir.

Dann gehe ich mal davon aus, dass elTorito bisher nur ein technisches Update auf NAV3.70 durchgeführt hat und vom Objektstand noch auf Financials 2.60 ist,
weil ab NAV3.xx die Standard-Objekte einen englischen Namen und lediglich deutsche Captions haben.

Und dann sollte doch zuerst der Objektstand und der Datenbestand von Financials 2.60 auf NAV2009 gebracht werden.
Der Datenbestand müsste dabei (sofern die Standard-Upgrade-Tools verwendet werden) von 2.60 --> NAV4 --> NAV2009 in zwei Schritten aktualisiert werden.

Erst wenn die Daten und Objekte ordentlich nach NAV2009 migriert wurden, würde ich mich um die SQL Migration kümmern.

Gruß
Jörg

Me Culpa...

hast Du einen deutschsprachigen Objektstand? (TabellenNAME Debitor statt Customer)

Ich hatte das falsch verstanden, die Tabellen Namen sind auf Englisch , ich hab das mit den Feld Captions verwechselt, die sind natürlich Deutsch.

Mit dem Upgrade Kit unseres NSC sollte der Objekt und Datenbestand ordentlich von 3.70 auf 2009 gebracht sein.

Das war eigentlich auch mein Plan, die Migration auf 2009 mit CC , dann erstmal laufen lassen, ggf. übersehene Probleme und fehlende Daten korrigieren (irgendwas wird immer übersehen , und irgendwie ist auch immer was). Und danach erst wollte ich die SQL Migration angehen.

Nun werde ich gedrängt direkt nach der Portierung auf 2009 die SQL Migration zu machen, meine Einwände und Forderung die Migration zu verzögern kamen "oben" nicht gut an, das soll gemacht werden weil ein anderes Projekt die SQL Datenbank benötigt , um Probleme usw würden wir uns danach kümmern.

Erst wenn die Daten und Objekte ordentlich nach NAV2009 migriert wurden, würde ich mich um die SQL Migration kümmern.

Die Migration von 3.70 auf 2009 bin ich jetzt schon seit Februar am testen, immer wieder Datenübernahme, dann testen testen testen, gucken gucken gucken... Fehler nachvollziehen, melden, vom NSC korrigieren lassen, wieder testen usw usw. Der Stand müsste mittlerweile passen, lediglich die Implementierung eines größeren Modul zur Branchenlösung fehlt noch, und dies Testen ...

Soweit es mir möglich ist versuche ich nun die für SQL unbrauchbaren Datensätze in der 3.70er Datenbank zu korrigieren. Als Basis dient mir gerade die Tabelle 79002 (der Mibuso report)

man merkt das nur daran, dass nach dem Drücken von ENTF scheinbar nichts passiert)

ja, ist mir jetzt auch aufgefallen, gibt viele Code Felder bei uns die ein Leerzeichen am Ende haben, ich bastel mir auch gerade ein Report der mir Codefelder mit Leer und Sonderzeichen listet, die hat der MibUso Report nicht gefunden.

Danke euch für eure Antworten !
Gruß
Peter

ich bastel mir auch gerade ein Report der mir Codefelder mit Leer und Sonderzeichen listet, die hat der MibUso Report nicht gefunden.

Die mit Leer und sofern es sich um CR,LF oder TAB handelt findet der Report auch die Sonderzeichen, wenn man die entsprechende Option einschaltet.

Hat man im ersten Durchlauf die erste Option eingeschaltet, kann man die Daten auch noch bearbeiten, bevor man Sie im 2. Durchlauf dann mit dem "RunUpdates"- Button übernimmt.

Die Leerzeichen am Ende sind, sondern sie nicht die Feldlänge überschreiten, eigentlich kein Problem für SQL, sie sorgen nur manchmal für merkwürdige Effekte.

Gruß, Fiddi

Hallo,

ich schon wieder ... ich hampel noch immer mit den Korrupten Daten herum... :(

Die letzten SQL Importe sind gescheitert an ß in Primärschlüsselder (ARtikelNr, DebitorNr, Kreditor...), habe mittels Report alle umbenannt, dann hats geknallt an einer Tabelle wo wir als Primärschlüssel z.B.: Kreuzgehänge, kreuzgehaenge, hatten , das mag SQL auch nicht, Schlüssel schon vorhanden, also hier eindeutigen Primärschlüssel hinzugefügt....

Nun wieder Abbruch bei irgendwelche ß Zeichen... Krieg ich alle ß mit dem Mibuso Report geändert? From Charakter ß to Y z.B.?

Zum Mäusemelken :(

Danke

Hallo,

wie ist denn die Sortierung deiner SQL-Datenbank eingestellt?
(Überprüfung in NAV: Datei - Datenbank ändern - Register "Sortierung")

Hallo JRenz,

wie ist denn die Sortierung deiner SQL-Datenbank eingestellt?
(Überprüfung in NAV: Datei - Datenbank ändern - Register "Sortierung")

Steht auf Collation Type = Windows Collection , Validate Collection, Description = Africa, ..blabla,.. German,... Accent-Sensitive = Ja)

Gibt es hier eigentlich Einstellungs Empfehlungen für die "ErstDatenbank"?

Hab den CC Client zuletzt auf Englisch umgestellt, vermute mal deswegen ist nun der SQL CC auch Englisch? Sprache kann ich da nicht ändern, im CC auch nicht weil gerade Prozess laeuft )


Danke.

mir wurde mal beigebracht, ich solle die Sortierung so wie im Anhang einstellen.
Ich weiß allerdings nicht, ob damit dein ß-Problem gelöst wäre.

Gruß
Jörg

2011-12-01 16 42 30.jpg

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

der SQL- Server mag kein ß in Code-Feldern er hätte dort lieber ss oder SS

Gruß, Fiddi

der SQL- Server mag kein ß in Code-Feldern er hätte dort lieber ss oder SS

Gruß, Fiddi

Ja, beim Import macht der SQL aus den ß scheinbar auch ein SS, allerdings blöd wenn es schon ein weiteren Datensatz gibt der das SS hatte (Weissman, Weißman)

Ich probier mal die o.g. Einstellung der SQL Sortierung, mal gucken ob das was bewirkt.

Danke

Ich probier mal die o.g. Einstellung der SQL Sortierung, mal gucken ob das was bewirkt.

Das wird dir wahrscheinlich nichts nutzen, tritt aber meistens bei Suchbegriffen von Namen auf, und ist deshalb recht einfach zu finden (debitoren,Kreditoren,Artikel).

Gruß, Fiddi

Guten Morgen,

Ich probier mal die o.g. Einstellung der SQL Sortierung, mal gucken ob das was bewirkt.

Das wird dir wahrscheinlich nichts nutzen, tritt aber meistens bei Suchbegriffen von Namen auf, und ist deshalb recht einfach zu finden (debitoren,Kreditoren,Artikel).
Gruß, Fiddi

hab das gestern noch umgestellt, dann Backup Import angeschmissen, heute morgen (vorhin, eben ... ) ins Büro gekommen, und gute Nachricht: "The 'Backup for SQL Migration' backup was succesfully restored. Fein, endlich, der erste Import nach SQL hat geklappt. Nun mal prüfen ob man da auch mit Arbeiten kann :)


Danke.

So. Ich wieder, eine Frage hätte ich noch, dann wäre die Sache für mich erstmal gelöst.

Habe jetzt die Ganzen Update Routinen nochmal durchgespielt, 3.70er DB nach 2009er DB übertragen, und die 2009er Datenbank nach SQL Migriert, in SQL Das fbk Backup eingespielt , war erfolgreich, und jetzt? ... Kann ich die Datenbank nicht starten , weil Windows Anmeldung nicht passt.

Wie krieg ich denn die User Synchronisiert? Damit ich die DB öffnen kann?
Security -> Synchronize ist ausgegraut, weil ich logischerweise noch nicht auf der Datenbank bin....

Steh grad voll aufn Schlauch

Danke.

Hallo,

wenn du die FBK eingelesen hast, musst du bevor du die DB schließt einen Windows- Benutzer in NAV einfügen mit Superrechten, der auch auf dem SQL-Server Admin- Rechte hat. Danach kann dieser Windows- Benutzer die DB wieder öffnen. Wenn die Benutzer von DB- Anmeldung auf Windows-Anmeldung umstellen willst, bleibt dir leider nichts anderes über als die Benutzer neu anzulegen. Das ist auch so, wenn du die Domäne wechselst.
Willst du weiterhin mit DB-Anmeldungen arbeiten, musst du die Benutzer als SQL-Anmeldungen mit Passwort auf dem SQL-Server anlegen (der SQL- Server ist hoffentlich im gemischten Modus (Windows u. DB-Anmeldungen) installiert)

Danach kannst du die NAV- Benutzer synchronisieren.

Gruß, Fiddi

Moin,

ich empfehle in dem Migrationsprozess auf Windows Login umzustellen, sofern ihr schon in einer Domäne seid.
Die Berechtigungen müsstest Du auch umkopieren können.

musst du bevor du die DB schließt einen Windows- Benutzer in NAV einfügen mit Superrechten, der auch auf dem SQL-Server Admin- Rechte hat. Danach kann dieser Windows- Benutzer die DB wieder öffnen.

Okay, dann war ich an der Stelle zu schnell ...

Nach der Migration soll die Anmeldung über Windows laufen , Domäne ist vorhanden, das "Neu" anlegen der Benutzer ist bei uns nicht weiter tragisch, haben nur ca 30 Stck. Ich Importiere gerade das fbk neu um dann vor dem Schließen ein SuperUser anzulegen.

Wenn man die Benutezr neu anlegt , gilt da etwas zu beachten? Ich denke da an die Zuordnungen innerhalb von Nav (IDM bzw Zugewiesene Benutzer ID) , werde ich gleich bestimmt herausfinden :)

An dieser Stelle euch nochmal ein riesen Dank für eure Antworten, ohne diese wäre ich total aufgeschmissen, und Frage mich warum ich auf meine Frage an unser NSC : "Ob es bei der SQL Migration wichtige Sachen zu beachten gibt" als Antwort nur das SQL Migrations Kit bekommen habe :(

Gott sei dank ist ein Ende in Sicht :) DANKE!

Hallo,

für die "Migration" von DB-Logins auf Windows-Logins gibt es bei den Upgrade-Tools ebenfalls eine fob, mit deren Hilfe die alten DB-Logins inklusive deren NAV-Rollen zu den zugehörigen Windows-Logins umgezogen werden können.
Da ich heute Urlaub habe und demnach nicht in der Firma bin, kann ich dir leider nicht auswendig sagen, wie die fob-Datei genau heißt.
Aber im englischen PDF-Dokument zu den Upgrade-Tools ist dieser Vorgang ausreichend beschrieben.

Gruß
Jörg