We are considering moving a few of our local Navision installations currently running Navsion 3.60 / 3.70 into our centrally hosted environment. Our central environment is using Microsoft SQL Server 2005.
Of course we could “just” upgrade the client to NAV 4.0 or NAV 5.0, but we really would prefer not to change anything there until they later are moved over to our global solution (running NAV 5.0).
So what I like to know is if Navsion 3.60 / 3.70 can run without any problems on Microsoft SQL Server 2005?
And how is the best way to move the database? Native Navision backup and restore into a new database created on SQL 2005? Or just taking moving the database?
There’s also an issue in some of the countries with different character sets (Greek and other Central Europe languages) and our central server is setup for Latin. Again the “good old non-unicode” issue!
1 - We use the 4.0SP3 executables to run 3.60and 3.70 databases on SQL 2005. Users did not “see” any change when we made the technical upgrade.
2 - To migrate we made a backup of the database using the Navision client, built a new database and made a restore using the new Navision client into our SQL server. It worked for us.
3 - Happily I can’t help with the charatcters set/code page issue (happy because we do not have that problem), just the good old Scandinavion character set problem.
4 I am sure you would do this anyway but… we always make a test conversion and ask our user to complete UAT before ew go live.
I had a 3.70B LV database on SQL2005 Express, (but for testing purposes only) simply attached .mdf. it was ome time ago, it was 2005 RC version…
There shoud be no problems with collation (I have the same situation with my native Latvian language) - if you create DB not specifying it, then your new db will be as if COLLATE database_default was used, in your case, Latin. You can set collation to whatewer you need, overriding server collation, at entire db level, or separate tables, or even some fields in table. Changing server collation is possible, too, but its a more serious task - Jorg can apparently help you more as forum’s SQL guru [;)]
I don’t think 3.6/3.7 is supported on SQL Server 2005, so it was not intended to run on that platform (I didn;t check this, so it might after all). Some people are running it though, and work through the issues as they encounter them. Just because someone has run this version of NAV on SQL Server 2005 doesn’t mean that it won’t cause problems. When you do get into trouble though, usually it’s the kind that shuts down the whole system. The choice becomes whether you want to schedule the time it takes to do a technical upgrade, and have everyone expect some down time, or do you want to run the risk of a system meltdown. Chances are you won’t get the meltdown (it’s a worst case scenario), but do you want to run the risk.
It’s not that you said so much new compared to the other replies. You just answer in a way that puts all the observations into a context which is great for taking decision upon. [:)]
Recommendation to our countries: If we should host your database, then we also need to upgrade your clients to NAV 4.0 (or NAV 5.0).
I’m currently a bit in a different state. Working on some new exiting code for DUG, and I’m not used to program ASP.NET in C#, so it really takes away most of my thoughts!
I think Daniel was given the answer for this. You have change compatibility to from 2005 to 2000 in server. Isn’t supported by Microsoft. It’s the same thing for running NAV 5.0 in Windows 2000. It can run smoothly but isn’t. supported. You can run for tests or internal development but I personally wouldn’t run a production system in 2005.
Even running Navision 3.70 in Terminal system and Windows 2003 has given me a few problems in the past.