6. Dezember 2009 15:49
Hallo msdynamics-Gemeinde,
in der Firma, in der ich arbeite wird aktuell Navision 4.0 eingesetzt. Demnächst steht ein "technisches" Update an, wo vom aktuellen SQL 2000 Server die Datenbank auf Windows Server 2008 64bit und SQL Server 2008 mit Navision 2009 als Client gewechselt wird.
Der neue Server ist auch betriebsbereit und nachdem ich auf dem 4.0 Server eine Navision Sicherung gemacht habe, auch diese unter SQL 2008 rückgesichert. Hat zwar lange gedauert, hat aber funktioniert.
Nun will ich die ganzen User synchronisieren, da diese nicht im SQL-Server existieren.
Wie mache ich das ?
Max
6. Dezember 2009 19:10
Hallo Max,
eigentlich sollte das mit 'Extras\Sicherheit\Alles synchronisieren' funktionieren. Je nach dem welches Sicherheitsmodell du bei der Erstellung der Datenbank gewählt hast, geht das sehr schnell (bei Simple) oder auch sehr lange (bei Standard).
Gruß, Fiddi
6. Dezember 2009 21:21
Hallo fiddi,
das habe ich bereits angestossen. Jedoch kommt dann die Meldung:
"Die Sicherheitssysteme von Microsoft Dynamics NAV Classic und SQL Server wurden nicht ordnungsgemäß synchronisiert. Die SQL-Server-Anmeldung 'Username' ist auf dem Server 'Servername' nicht vorhanden."
Im SQL Server Management Studio habe ich unter Security die User angelegt, und die Navision Datenbank zugewiesen mit der Rolle Public.
Wenn ich Einzeln synchronisere, dann geht das ohne das eine Meldung kommt. Beim Login mit diesem User bekomme ich die Meldung
"Sie können Microsoft Dynamics NAV Classic Client nicht starten, da Sie für den SQL-Server nicht die Berechtigung zum Anzeigen des Serverstatus (VIEW SERVER STATE) besitzen. Wenden Sie sich an den Systemadministrator"
Max
6. Dezember 2009 21:57
Hi,
Nun ja, die native Sicherung FBK enthält ja keinerlei SQL Server seitigen Logins/User - einzig die in NAV definierten Logins sind dabei.
(Deshalb ist der Weg eines Updates über ein natives Backup/Restore nicht empfehlenswert - ist nicht nur extrem zeitaufwendig, es fehlen auch sämtlich SQL seitigen Optimierungen die ggf. implementiert sind. Man hätte das ganze auch mit SQL Backups schneller und zuverlässiger machen können ...)
Aber egal: Man müsste nun erstmal die
SQL Logins aus dem alten 2000er Server in den neuen Übertragen. Siehe:
http://support.microsoft.com/kb/246133/en-usDann kann man dazu die
SQL User anlegen (die wären in einem SQL Backup enthalten, mit nem FBK muss dies nun manuell oder per TSQL Script erfolgen).
Erst zum Schluss kann nun die NAV Synchronisierung erfolgen (die mit "Standard" Sicherheitsmodell nicht wirklich notwendig ist).
Das mit der VIEW_ERVER_STATE Permission hört sich schon seltsam an. WOher diese Meldung kommt ist schwer zu sagen (ein Bug?) aber umgehen könnte man das mit
GRANT VIEW_SERVER_STATE TO PUBLICDann darf jeder alle System-Infos LESEN.
6. Dezember 2009 22:15
Hm, dann wäre es wohl besser, ein FULLBACKUP der Navision 4.0 DB auf dem SQL-Server 2000 zu erstellen und dieses dann auf dem neuen Server SQL 2008 zurückzusichern ?
Jetzt weiß ich natürlich nicht, ob es sql-seitig Optimierungen in der SQL 2000 DB gibt, was wären das denn zum Beispiel auf Navision bezogen ?
Max
7. Dezember 2009 10:26
Also im einfachsten Fall würde auch ein "Detach DB 2000 - Copy mdf/ndf to 2008 - Attach 2008" genügen. EIn SQL Backup ist eine 1:1 Kopie aller belegten DB Seiten, also Daten inkl. Indexe und SQL Server Objekte (Views, Prozeduren, etc.). Wurden solche Objekte erstellt - z.B. optimierte SQL Indexe, Füllfaktoren o.ä. - dann sind diese im FBK nicht enthalten. EIn FBK enthält neben einigen Metadaten nur die Tabellen-Daten.
Während man beim Restore eines SQL Backups also eine identische Kopie (inkl. aller Fehler) des Original erhält, so wird beim FBK Restore alles von Grund auf neu erzeugt (deshalb dauert das so lange).
7. Dezember 2009 14:04
Hallo Jörg,
danke für Deine Erklärung.
GRANT VIEW_SERVER_STATE to PUBLIC erzeugt auf dem Server einen Syntax Error
Verstehe ich das richtig, dass für die einfachste Vorgehensweise detach/attach auf dem neuen Server die gleiche Plattenkonfiguration sein muss ? (physikalische Laufwerke)
Grundsätzlich sollen die Indizes neu aufgebaut werden (wegen der eventuell inkl. Fehler!) auf dem neuen Server, dass kann ich mit Hilfe von Detach/Attach ja auch machen ? (Nav-Objekte Keys deaktivieren, speichern, und nochmal andersherum, das erzeugt dann neue Indextabellen ?)
Max
7. Dezember 2009 14:18
Ups ... richtig, korrekt müsste es heissen:
GRANT VIEW SERVER STATE TO PUBLIC
Beim "Detach/Attach" verfahren kann man die Dateien auch auf andere Laufwerke verteilen - beim "Attach" kann man das neue Mapping entsprechend angeben.
Indexe werden dabei natürlich nicht neu aufgebaut. Aber mit dem "Maintain SQL Index" = FALSE - Save -"Maintain SQL Index" = TRUE sollte es schon klappen.
Es würde aber wohl schon genügen, einfach nach dem Attach einen vollständigen "Index Rebuild" (ALTER INDEX REBUILD) laufen zu lassen ...
3. Februar 2010 19:46
Hallo Jörg,
hat geklappt. Jedoch ist es so wie Du schon geschrieben hast, der Restore von Native in die neue SQL 2008 DB dauert sehr lange..... gähn, bis zu 20 Stunden.
Die Berechtigung konnte ich auch erfolgreich vergeben.
Als weiteren Test habe ich nun das SQL-Fullbackup von SQL 2000 in eine neue SQL 2008 DB rückgesichert.
Hier erscheint nun beim NAV-Client folgende Meldung (wenn ich connecten will)
"Der Datenbank-Kompatibilitätsgrad 80 ist zu niedrig für diese Version von Microsoft Dynamics NAV Classic. Ändern Sie den Kompatibilitätsgrad in 90,bevor Sie die Datenbank erneut öffnen."
Hast Du ne Idee, was ich machen kann ? Liegt das an den Eigenschaften der erstellten DB im SQL 2008 Server ?
Danke
Max
3. Februar 2010 21:02
Hallo Max,
zunächst zu deiner Frage: Den Kompatibilitätsgrad kannst du in den Eigenschaften der Datenbank unter "Optionen" einstellen. Stell bitte beim SQL Server 2008 auf 100. Der Kompatibilitätsgrad wirkt sich auf die Art aus, wie SQL Server mit der Datenbank umgeht, beispielsweise welche T-SQL Version unterstützt wird.
Weiterhin: Die obige Fehlermeldung lässt mich vermuten, dass ihr nicht wie angegeben ein technisches Upgrade auf NAV 2009 sondern auf NAV 2009 SP1 macht. Bis zu 2009 brauchte man das Traceflag 4616, seit SP1 wird VIEW SERVER STATE für den Zugriff auf die Verbindungsinformationen genutzt (siehe auch
SQL Server Trace Flag 4616 no longer required for Dynamics NAV 2009 SP1).
Wichtig: Ein Update auf NAV 2009 SP1 von früheren Versionen wird von Microsoft nur noch komplett unterstützt, sprich ein Upgrade aller Dateien und aller Objekte (inkl. Businesslogik)! Das ist umso gefährlicher, als dass NAV 4.0 seit Januar aus dem normalen Support gefallen ist und ihr somit so oder so eine nicht unterstützte Datenbank und ebenfalls eine nicht unterstützte Konstellation nutzt. Zitat: "Note: To upgrade to Microsoft Dynamics NAV 2009 SP1 from Microsoft Dynamics NAV 2009 or any previous version, you must perform a full upgrade of all files and objects to ensure they are compatible with the Microsoft Dynamics NAV 2009 SP1 platform. You must also update Web services."
Also auch wenn mir bisher nur Änderungen am Page-Handling (weggefallener Trigger) und an den Web Services bekannt sind, so sind es wahrscheinlich auch einige andere Dinge die einen einwandfreien Betrieb in einer anderen Konstellation verhindern könnten.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.