Umstellung Native auf SQL DB
23. Februar 2009 09:35
Hallo,
wir haben aktuell eine 3.70er native DB im Einsatz und möchten auf 5.1 SQL umstellen.
Ich habe versucht die 3.70er native Datensicherung in eine leere 5.1 native Datenbank einzulesen, das dauert mehrere Tage.
1.
Nun meine Fragen, kann ich denn eigentlich nicht unter SQL eine neue leere 5.1 SQL navision DB anlegen und mit dem 5.1 Client direkt die 3.70er Sicherung einspielen?? Klar vorher muss in native Datumsprüfung laufen usw...
2.
ODer ist es sinnvoll oder notwendig die alte 3.70er native mit dem 5.1 native Client zu öffnen konvertieren und dann erst sicherung ziehen und in sql datenbank einspielen???
3.
Ist denn das Ergebnis dasselbe wenn ich eine olle Sicherung in eine neue Datenbank einspiele oder wenn ich vorher auf den aktuellen native stand konvertiere und diese Sicherung einspielen???
Viele Grüße
Tesa.
wir haben aktuell eine 3.70er native DB im Einsatz und möchten auf 5.1 SQL umstellen.
Ich habe versucht die 3.70er native Datensicherung in eine leere 5.1 native Datenbank einzulesen, das dauert mehrere Tage.
1.
Nun meine Fragen, kann ich denn eigentlich nicht unter SQL eine neue leere 5.1 SQL navision DB anlegen und mit dem 5.1 Client direkt die 3.70er Sicherung einspielen?? Klar vorher muss in native Datumsprüfung laufen usw...
2.
ODer ist es sinnvoll oder notwendig die alte 3.70er native mit dem 5.1 native Client zu öffnen konvertieren und dann erst sicherung ziehen und in sql datenbank einspielen???
3.
Ist denn das Ergebnis dasselbe wenn ich eine olle Sicherung in eine neue Datenbank einspiele oder wenn ich vorher auf den aktuellen native stand konvertiere und diese Sicherung einspielen???
Viele Grüße
Tesa.
Re: Umstellung Native auf SQL DB
23. Februar 2009 10:15
Hallo Tesarolle,
du kannst das Einlesen der FBK eigentlich nur dadurch beschleunigen, indem du vor dem Ziehen der FBK in deiner zu sichernden DB alle nicht benötigten Schlüssel (alle außer 1 bzw. Clustered) auf allen Tabellen dektivierst. Das geht eigentlich ganz einfach mit einem Report auf der Tabelle Key. Durch die deaktivierten Schlüssel wird deine Datensicherung zwar nicht unbedingt kleiner, das Rücksichern geht aber sehr viel schneller. Du kannst dann nach und nach die Schlüssel wieder aktivieren.
Eine weitere Möglichkeit könnte sein, das Flag MaintainSQlIndex bei den Keys auszuschalten(Ich weiß nicht, ob 3.70 das schon kann. Falls nicht: FOB ziehen, neue SQL-DB aufbauen, FOB einlesen und bei allen außer den Clustered-Indexen das Flag abschalten. Danach FBK mit den Daten einlesen). Das sorgt dafür, das der SQL-Server keine Schlüssel beim Einlesen der FBK aufbaut, NAV aber - wenn auch grottenlangsam
- funktionsfähig bleibt. Danach kannst du dann das Flag wieder aktivieren.
Gruß, Fiddi
du kannst das Einlesen der FBK eigentlich nur dadurch beschleunigen, indem du vor dem Ziehen der FBK in deiner zu sichernden DB alle nicht benötigten Schlüssel (alle außer 1 bzw. Clustered) auf allen Tabellen dektivierst. Das geht eigentlich ganz einfach mit einem Report auf der Tabelle Key. Durch die deaktivierten Schlüssel wird deine Datensicherung zwar nicht unbedingt kleiner, das Rücksichern geht aber sehr viel schneller. Du kannst dann nach und nach die Schlüssel wieder aktivieren.
Eine weitere Möglichkeit könnte sein, das Flag MaintainSQlIndex bei den Keys auszuschalten(Ich weiß nicht, ob 3.70 das schon kann. Falls nicht: FOB ziehen, neue SQL-DB aufbauen, FOB einlesen und bei allen außer den Clustered-Indexen das Flag abschalten. Danach FBK mit den Daten einlesen). Das sorgt dafür, das der SQL-Server keine Schlüssel beim Einlesen der FBK aufbaut, NAV aber - wenn auch grottenlangsam
- funktionsfähig bleibt. Danach kannst du dann das Flag wieder aktivieren.Gruß, Fiddi
Re: Umstellung Native auf SQL DB
23. Februar 2009 10:33
Hallo Fiddi,
vielen Dank für Deinen BEitrag.
Ich will das einlesen nicht beschleunigen, meine Fragen sind ja grundsätzlicher Natur.
Das mit den schlüsseln ist mir bekannt, da ich allerdings nur das Zeitfenster von einem WE für die Umstellung habe, habe ich keinen Vorteil der sich durch nachträgliche Aktivierung der Schlüssel ergibt da ich in Summe ja dieselbe Zeit benötige nur Zeitversetzt.
Meine 3 Fragen wären noch offen
Gruß
Tesa.
vielen Dank für Deinen BEitrag.
Ich will das einlesen nicht beschleunigen, meine Fragen sind ja grundsätzlicher Natur.
Das mit den schlüsseln ist mir bekannt, da ich allerdings nur das Zeitfenster von einem WE für die Umstellung habe, habe ich keinen Vorteil der sich durch nachträgliche Aktivierung der Schlüssel ergibt da ich in Summe ja dieselbe Zeit benötige nur Zeitversetzt.
Meine 3 Fragen wären noch offen
Gruß
Tesa.
Re: Umstellung Native auf SQL DB
23. Februar 2009 11:26
Hallo Tesarolle,
welche NAV-Version du benutzt dürfte ziemlich gleich sein. Die Lösung 5.1SQL mit 3.70 FBK sollte eigentlich funktionieren. (am besten vorher mit einer CRONUS probieren).
Wichtig ist nur, wie du schon selbst erkannt hast, vorher die Daten zu prüfen (Es wird nicht nur das Datum geprüft, sondern auch Umlaute in Code-Feldern).
Mein Vorschlag zielte eigentlich darauf ab, dir ein größeres Zeitfenster zu verschaffen. Mit dem Flag MaintainSQL-Index kannst du steuern welche Indexe im SQL-Server tatsächlich erzeugt werden. Diese kannst du auch nachträglich aktivieren ohne das du in NAV Funktionalität verlierst (es geht halt nur langsamer). Wenn das Zeitfenster nicht reicht, würde ich die Version :erst FOB, SQL-Keys dektivieren, FBK einspielen,SQL-Schlüssel nach gewünschter Priorität (Buchen, Auswerten,..) aktivieren.
Gruß, Fiddi
welche NAV-Version du benutzt dürfte ziemlich gleich sein. Die Lösung 5.1SQL mit 3.70 FBK sollte eigentlich funktionieren. (am besten vorher mit einer CRONUS probieren).
Wichtig ist nur, wie du schon selbst erkannt hast, vorher die Daten zu prüfen (Es wird nicht nur das Datum geprüft, sondern auch Umlaute in Code-Feldern).
Mein Vorschlag zielte eigentlich darauf ab, dir ein größeres Zeitfenster zu verschaffen. Mit dem Flag MaintainSQL-Index kannst du steuern welche Indexe im SQL-Server tatsächlich erzeugt werden. Diese kannst du auch nachträglich aktivieren ohne das du in NAV Funktionalität verlierst (es geht halt nur langsamer). Wenn das Zeitfenster nicht reicht, würde ich die Version :erst FOB, SQL-Keys dektivieren, FBK einspielen,SQL-Schlüssel nach gewünschter Priorität (Buchen, Auswerten,..) aktivieren.
Gruß, Fiddi
Re: Umstellung Native auf SQL DB
23. Februar 2009 14:01
Hallo Fiddi,
jetzt hast Du mich neugierig gemacht.
Hast Du denn so einen Report der die Schlüssel deaktiviert?
Die Tabelle Key kann ich in meiner Native DB nicht finden.
Ich müsste also zuerst Schlüssel deaktivieren in der Produktiv DB, dann Sicherung in ein FBK, dann das FBK in SQL einlesen und dann SChlüssel für Schlüssel wieder aktivieren, Richtig???
Viele Grüße
Tesa.
jetzt hast Du mich neugierig gemacht.
Hast Du denn so einen Report der die Schlüssel deaktiviert?
Die Tabelle Key kann ich in meiner Native DB nicht finden.
Ich müsste also zuerst Schlüssel deaktivieren in der Produktiv DB, dann Sicherung in ein FBK, dann das FBK in SQL einlesen und dann SChlüssel für Schlüssel wieder aktivieren, Richtig???
Viele Grüße
Tesa.
Re: Umstellung Native auf SQL DB
23. Februar 2009 14:41
Hallo Tesarolle,
die Tabelle findest du auch nicht im Designer, sondern nur wenn du einen neuen Report erstellst, und Key als Tabelle angibst. Das Funktioniert übrigens genauso mit einer Form , falls du dir vorher mal ansehen willst was in der Tabelle drin ist.
In der Key ist für jede Tabelle und jeden Schlüssel dieser Tabelle ein Eintrag enthalten beginnend mit 1 für den Primärschlüssel. Du musst in deinem Report jetzt bei allen Schlüsseln das Flag 'MaintainSQLindex' auf False setzten, die nicht primär (also 1) bzw. Clustered sind.
Das würde ich auf dem SQL-Server in einer leeren 5.1-Datenbank mit dem Objektstand aus der 3.70 machen (evtl. einen Test-Mandanten anlegen, falls der Report nicht ohne Mandant läuft). Nachdem alle SQL-Schlüssel deaktiviert sind, kannst du jetzt die FBK einspielen (nur die Daten).
Im Anschluss daran kannst du beginnen, die SQL-Schlüssel wieder per Report zu aktivieren. Und zwar in der Reihenfolge wie du Sie am dringendsten benötigst (wg. Belege buchen, auswerten, usw.). NAV ist aber dann schon Betriebsbereit (wenn auch langsam).
Gruß, Fiddi
die Tabelle findest du auch nicht im Designer, sondern nur wenn du einen neuen Report erstellst, und Key als Tabelle angibst. Das Funktioniert übrigens genauso mit einer Form
, falls du dir vorher mal ansehen willst was in der Tabelle drin ist.In der Key ist für jede Tabelle und jeden Schlüssel dieser Tabelle ein Eintrag enthalten beginnend mit 1 für den Primärschlüssel. Du musst in deinem Report jetzt bei allen Schlüsseln das Flag 'MaintainSQLindex' auf False setzten, die nicht primär (also 1) bzw. Clustered sind.
Das würde ich auf dem SQL-Server in einer leeren 5.1-Datenbank mit dem Objektstand aus der 3.70 machen (evtl. einen Test-Mandanten anlegen, falls der Report nicht ohne Mandant läuft). Nachdem alle SQL-Schlüssel deaktiviert sind, kannst du jetzt die FBK einspielen (nur die Daten).
Im Anschluss daran kannst du beginnen, die SQL-Schlüssel wieder per Report zu aktivieren. Und zwar in der Reihenfolge wie du Sie am dringendsten benötigst (wg. Belege buchen, auswerten, usw.). NAV ist aber dann schon Betriebsbereit (wenn auch langsam).
Gruß, Fiddi